Uploaded image for project: 'Apache Gora'
  1. Apache Gora
  2. GORA-381

Fix Guava dependency mismatch post GoraCI

    XMLWordPrintableJSON

    Details

    • Type: New Feature
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 0.6
    • Fix Version/s: 0.6
    • Component/s: gora-cassandra
    • Labels:

      Description

      I recently broke the build after committing GORA-374.
      This only happened when I failed to flush my local .m2 cache and that is why I didn't catch it in time.
      There is a mismatch in the Gurava versioning which means we get the following when attempting to set up the local C* server for tests.

      jb-9-Data.db'), SSTableReader(path='target/test/var/lib/cassandra/data/system/schema_keyspaces/system-schema_keyspaces-jb-19-Data.db'), SSTableReader(path='target/test/var/lib/cassandra/data/system/schema_keyspaces/system-schema_keyspaces-jb-16-Data.db'), SSTableReader(path='target/test/var/lib/cassandra/data/system/schema_keyspaces/system-schema_keyspaces-jb-3-Data.db')]
      14/09/28 04:16:40 ERROR service.CassandraDaemon: Exception in thread Thread[CompactionExecutor:15,1,main]
      java.lang.NoSuchMethodError: com.google.common.util.concurrent.RateLimiter.acquire(I)V
      at org.apache.cassandra.io.compress.CompressedThrottledReader.reBuffer(CompressedThrottledReader.java:40)
      at org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:280)
      at org.apache.cassandra.io.sstable.SSTableScanner$KeyScanningIterator.computeNext(SSTableScanner.java:256)
      at org.apache.cassandra.io.sstable.SSTableScanner$KeyScanningIterator.computeNext(SSTableScanner.java:197)
      at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
      at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
      at org.apache.cassandra.io.sstable.SSTableScanner.hasNext(SSTableScanner.java:177)
      at org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:144)
      at org.apache.cassandra.utils.MergeIterator$ManyToOne.<init>(MergeIterator.java:87)
      at org.apache.cassandra.utils.MergeIterator.get(MergeIterator.java:46)
      at org.apache.cassandra.db.compaction.CompactionIterable.iterator(CompactionIterable.java:47)
      at org.apache.cassandra.db.compaction.CompactionTask.runWith(CompactionTask.java:129)
      at org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)
      at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
      at org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:60)
      at org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
      at org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionTask.run(CompactionManager.java:197)
      at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
      at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
      at java.util.concurrent.FutureTask.run(FutureTask.java:166)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
      at java.lang.Thread.run(Thread.java:724)

      We need to address this before we move onwards. Possibly to exclude Guava within the transient gora-core inheritence and then add it as an indivdual import on the gora-cassandra side.
      We will soon find out once I hack this tomorrow.

        Attachments

          Activity

            People

            • Assignee:
              lewismc Lewis John McGibbney
              Reporter:
              lewismc Lewis John McGibbney
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: