[ 
https://issues.apache.org/jira/browse/OAK-7332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16395352#comment-16395352
 ] 

Andrei Dulceanu commented on OAK-7332:
--------------------------------------

As mentioned in the issue description, the patch changes {{oak-benchmarks}} to 
remove the transitive dependency to {{concurrentlinkedhashmap}} from 
{{solr-core}}. After applying it, I could successfully run benchmarks on 
various fixtures including {{Oak-Segment-Tar}}, {{Oak-Segment-Tar-Cold}}, 
{{Oak-Segment-Tar-DS}}, {{Oak-Composite-Memory-Store}}, etc.

[~mduerig], [~frm] do you see any issues for this approach? 

> Benchmarks failure on Oak-Segment-* fixtures due to concurrentlinkedhashmap 
> version conflict 
> ---------------------------------------------------------------------------------------------
>
>                 Key: OAK-7332
>                 URL: https://issues.apache.org/jira/browse/OAK-7332
>             Project: Jackrabbit Oak
>          Issue Type: Task
>          Components: benchmarks, segment-tar
>            Reporter: Andrei Dulceanu
>            Assignee: Andrei Dulceanu
>            Priority: Major
>             Fix For: 1.9.0, 1.10
>
>         Attachments: OAK-7332.patch
>
>
> The changes needed for OAK-7259 rely on 
> {{com.googlecode.concurrentlinkedhashmap/concurrentlinkedhashmap-lru}} 1.4.2, 
> which is embedded in {{oak-segment-tar}}. This conflicts with the transitive 
> dependency coming from {{org.apache.solr/solr-core}} in {{oak-benchmarks}}, 
> which depends on {{concurrentlinkedhashmap-lru}} 1.2. Therefore, running 
> benchmarks on {{Oak-Segment-*}} fixtures fails with the following exception:
> {noformat}
> 04:35:44 Exception in thread "main" java.lang.NoSuchMethodError: 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Builder.maximumWeightedCapacity(J)Lcom/googlecode/concurrentlinkedhashmap/ConcurrentLinkedHashMap$Builder;
> 04:35:44     at 
> org.apache.jackrabbit.oak.segment.CommitsTracker.<init>(CommitsTracker.java:57)
> 04:35:44     at 
> org.apache.jackrabbit.oak.segment.CommitsTracker.<init>(CommitsTracker.java:51)
> 04:35:44     at 
> org.apache.jackrabbit.oak.segment.SegmentNodeStoreStats.<init>(SegmentNodeStoreStats.java:64)
> 04:35:44     at 
> org.apache.jackrabbit.oak.segment.scheduler.LockBasedScheduler.<init>(LockBasedScheduler.java:171)
> 04:35:44     at 
> org.apache.jackrabbit.oak.segment.scheduler.LockBasedScheduler$ObservableLockBasedScheduler.<init>(LockBasedScheduler.java:352)
> 04:35:44     at 
> org.apache.jackrabbit.oak.segment.scheduler.LockBasedScheduler$LockBasedSchedulerBuilder.build(LockBasedScheduler.java:100)
> 04:35:44     at 
> org.apache.jackrabbit.oak.segment.SegmentNodeStore.<init>(SegmentNodeStore.java:169)
> 04:35:44     at 
> org.apache.jackrabbit.oak.segment.SegmentNodeStore.<init>(SegmentNodeStore.java:63)
> 04:35:44     at 
> org.apache.jackrabbit.oak.segment.SegmentNodeStore$SegmentNodeStoreBuilder.build(SegmentNodeStore.java:121)
> 04:35:44     at 
> org.apache.jackrabbit.oak.fixture.SegmentTarFixture.setUpCluster(SegmentTarFixture.java:211)
> 04:35:44     at 
> org.apache.jackrabbit.oak.fixture.OakRepositoryFixture.setUpCluster(OakRepositoryFixture.java:145)
> 04:35:44     at 
> org.apache.jackrabbit.oak.fixture.OakRepositoryFixture.setUpCluster(OakRepositoryFixture.java:141)
> 04:35:44     at 
> org.apache.jackrabbit.oak.benchmark.AbstractTest.createRepository(AbstractTest.java:655)
> 04:35:44     at 
> org.apache.jackrabbit.oak.benchmark.AbstractTest.run(AbstractTest.java:202)
> 04:35:44     at 
> org.apache.jackrabbit.oak.benchmark.BenchmarkRunner.main(BenchmarkRunner.java:516)
> 04:35:44     at 
> org.apache.jackrabbit.oak.run.BenchmarkCommand.execute(BenchmarkCommand.java:27)
> 04:35:44     at org.apache.jackrabbit.oak.run.Main.main(Main.java:54)
> {noformat}
> A possible solution to mitigate this is to exclude the transitive dependency 
> to {{com.googlecode.concurrentlinkedhashmap/concurrentlinkedhashmap-lru}} 
> from {{org.apache.solr/solr-core}} in {{oak-benchmarks}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to