Cassandra
  1. Cassandra
  2. CASSANDRA-4958

Snappy 1.0.4 doesn't work on OSX / Java 7

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Fix Version/s: 1.2.6
    • Component/s: None
    • Labels:
      None

      Description

        Activity

        Colin Taylor created issue -
        Colin Taylor made changes -
        Field Original Value New Value
        Description https://github.com/xerial/snappy-java/issues/6

        Fixed in 1.0.5-M3 see :

        https://github.com/xerial/snappy-java/issues/6

        Colin Taylor made changes -
        Summary Snappy 1.0.4 doesn't work on OSX/ Java 7 Snappy 1.0.4 doesn't work on OSX / Java 7
        Hide
        Sylvain Lebresne added a comment -

        I'm fine with upgrading snappy-java, though is 1.0.5-M3 really released? I doesn't appear in http://code.google.com/p/snappy-java/downloads/list for instance. Does someone know if you're supposed to bake it yourself?

        Show
        Sylvain Lebresne added a comment - I'm fine with upgrading snappy-java, though is 1.0.5-M3 really released? I doesn't appear in http://code.google.com/p/snappy-java/downloads/list for instance. Does someone know if you're supposed to bake it yourself?
        Hide
        Jonathan Ellis added a comment -

        It looks like the M stands for Milestone, so it's beta (alpha?) quality.

        Show
        Jonathan Ellis added a comment - It looks like the M stands for Milestone, so it's beta (alpha?) quality.
        Hide
        Konstantin Zadorozhny added a comment -

        We have to compile M3 ourselves for our cluster on FreeBSD. It runs ok with 1.1.6 and openjdk7.

        Show
        Konstantin Zadorozhny added a comment - We have to compile M3 ourselves for our cluster on FreeBSD. It runs ok with 1.1.6 and openjdk7.
        Hide
        Colin Taylor added a comment -

        M3 is in maven repo:
        http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22snappy-java%22

        The git history seems pretty stable https://github.com/xerial/snappy-java/commits/develop but maybe 1.5 isn't too far away.

        The workaround for those who use the cassandra-maven-plugin is an explicit dependency:

         
                        <dependencies>
                            <dependency>
                                <groupId>org.xerial.snappy</groupId>
                                <artifactId>snappy-java</artifactId>
                                <version>1.0.5-M3</version>
                                <type>jar</type>
                            </dependency>
                        </dependencies>
        
        Show
        Colin Taylor added a comment - M3 is in maven repo: http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22snappy-java%22 The git history seems pretty stable https://github.com/xerial/snappy-java/commits/develop but maybe 1.5 isn't too far away. The workaround for those who use the cassandra-maven-plugin is an explicit dependency: <dependencies> <dependency> <groupId>org.xerial.snappy</groupId> <artifactId>snappy-java</artifactId> <version>1.0.5-M3</version> <type>jar</type> </dependency> </dependencies>
        Hide
        Sylvain Lebresne added a comment -

        I'm not too fan of using a beta version, no matter how stable the git history looks like. So I see two way of moving forward:

        1. maybe M3 is indeed pretty stable and the author of snappy-java just didn't take the time to do a stable release. But imo only the snappy-java author knows that and we should maybe bug him to see if he would be good doing a stable release or if not, when we can expect one.
        2. there's apparently a pure java implem of snappy (https://github.com/dain/snappy). It's slightly slower on decompression so I'm not sure we want to have it the default, but we could use it as a fallback when loading the native version fails. Which would also give us a fallback for more exotic platform where the native version is just not available.

        I note that I list both possibilities, but I'd lie if I said any of them was on my priority list. So feel free to bug the snappy-java author if you want this issue resolved

        Show
        Sylvain Lebresne added a comment - I'm not too fan of using a beta version, no matter how stable the git history looks like. So I see two way of moving forward: maybe M3 is indeed pretty stable and the author of snappy-java just didn't take the time to do a stable release. But imo only the snappy-java author knows that and we should maybe bug him to see if he would be good doing a stable release or if not, when we can expect one. there's apparently a pure java implem of snappy ( https://github.com/dain/snappy ). It's slightly slower on decompression so I'm not sure we want to have it the default, but we could use it as a fallback when loading the native version fails. Which would also give us a fallback for more exotic platform where the native version is just not available. I note that I list both possibilities, but I'd lie if I said any of them was on my priority list. So feel free to bug the snappy-java author if you want this issue resolved
        Hide
        T Jake Luciani added a comment -

        You can also look at CASSANDRA-5038 I've been using it without issue and it should work fine with Java7.

        Show
        T Jake Luciani added a comment - You can also look at CASSANDRA-5038 I've been using it without issue and it should work fine with Java7.
        Gavin made changes -
        Workflow no-reopen-closed, patch-avail [ 12733928 ] patch-available, re-open possible [ 12752077 ]
        Gavin made changes -
        Workflow patch-available, re-open possible [ 12752077 ] reopen-resolved, no closed status, patch-avail, testing [ 12755170 ]
        Hide
        Yuki Morishita added a comment -
        Show
        Yuki Morishita added a comment - Finally snappy-java 1.0.5 is out. http://search.maven.org/#artifactdetails%7Corg.xerial.snappy%7Csnappy-java%7C1.0.5%7Cbundle Time to upgrade?
        Hide
        Sylvain Lebresne added a comment -

        Time to upgrade?

        Sure, mind giving it a shot?

        Show
        Sylvain Lebresne added a comment - Time to upgrade? Sure, mind giving it a shot?
        Hide
        Yuki Morishita added a comment -

        Here it is, against 1.2 branch.

        Show
        Yuki Morishita added a comment - Here it is, against 1.2 branch.
        Yuki Morishita made changes -
        Attachment 0001-CASSANDRA-4958-1.2.patch [ 12583662 ]
        Yuki Morishita made changes -
        Status Open [ 1 ] Patch Available [ 10002 ]
        Fix Version/s 1.2.6 [ 12324449 ]
        Hide
        Sylvain Lebresne added a comment -

        I'd have trust you going ninja style on that one . But +1.

        Show
        Sylvain Lebresne added a comment - I'd have trust you going ninja style on that one . But +1.
        Hide
        Yuki Morishita added a comment -

        Committed.

        Show
        Yuki Morishita added a comment - Committed.
        Yuki Morishita made changes -
        Status Patch Available [ 10002 ] Resolved [ 5 ]
        Assignee Yuki Morishita [ yukim ]
        Reviewer slebresne
        Resolution Fixed [ 1 ]
        Hide
        Michael Kjellman added a comment -

        Yuki Morishita best ninja fix, maybe ever! thank you!

        Show
        Michael Kjellman added a comment - Yuki Morishita best ninja fix, maybe ever! thank you!
        Hide
        Patrick Monfette added a comment - - edited

        I believe this fix (going to snappy 1.0.5) broke Cassandra on CentOS 5 for us. We're using the RPM package.

        I upgraded from Cassandra 1.2.5 (which was using snappy 1.0.4) and I couldn't get 1.2.6 to start up properly and I had to rollback to 1.2.5.

        Here's the error I was getting when starting Cassandra 1.2.6 after the upgrade.

        ERROR [SSTableBatchOpen:5] 2013-07-05 16:35:22,466 CassandraDaemon.java (line 192) Exception in thread Thread[SSTableBatchOpen:5,5,main]
        java.lang.RuntimeException: Cannot create CompressionParameters for stored parameters
                at org.apache.cassandra.io.compress.CompressionMetadata.<init>(CompressionMetadata.java:99)
                at org.apache.cassandra.io.compress.CompressionMetadata.create(CompressionMetadata.java:63)
                at org.apache.cassandra.io.util.CompressedSegmentedFile$Builder.complete(CompressedSegmentedFile.java:51)
                at org.apache.cassandra.io.sstable.SSTableReader.load(SSTableReader.java:411)
                at org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:201)
                at org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:154)
                at org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:241)
                at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
                at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
                at java.util.concurrent.FutureTask.run(FutureTask.java:138)
                at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
                at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
                at java.lang.Thread.run(Thread.java:662)
        Caused by: org.apache.cassandra.exceptions.ConfigurationException: SnappyCompressor.create() threw an error: java.lang.NoClassDefFoundError Could not initialize class org.xerial.snappy.Snappy
                at org.apache.cassandra.io.compress.CompressionParameters.createCompressor(CompressionParameters.java:179)
                at org.apache.cassandra.io.compress.CompressionParameters.<init>(CompressionParameters.java:71)
                at org.apache.cassandra.io.compress.CompressionMetadata.<init>(CompressionMetadata.java:95)
                ... 12 more
        Caused by: java.lang.reflect.InvocationTargetException
                at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
                at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                at java.lang.reflect.Method.invoke(Method.java:597)
                at org.apache.cassandra.io.compress.CompressionParameters.createCompressor(CompressionParameters.java:156)
                ... 14 more
        Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.xerial.snappy.Snappy
                at org.apache.cassandra.io.compress.SnappyCompressor.create(SnappyCompressor.java:45)
                ... 19 more
        

        I did try to implement the following documented fix that seemed related to our issue but it did not work:

        http://www.datastax.com/docs/1.0/troubleshooting/index#snappy

        Furthermore, I suspect this is not the exact same problem since 1.2.5 was working perfectly fine for us without the above fix. We only did an update of the Cassandra package to 1.2.6, diffed and merged the yaml config file and tried to start it back up, like all the other previous upgrades we did as version 1.2.x came out.

        I also fully updated all server packages in case it had something to do with an old library somwehere else or something but it did not work either.

        We're running the latest CentOS 5.9, 64 bits, fully updated.

        We're running java 1.6.0 from Sun (not OpenJDK)

        java version "1.6.0_26"
        Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
        Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
        

        Here is the content of my /tmp folder on the server (those get created when I start up Cassandra. The 1.0.5 is the one that got created when I was trying to start up Cassandra 1.2.6. It seems quite small compared to version 1.0.4 (which was created by version 1.2.5).

        -rwxr-xr-x  1 cassandra       cassandra       991112 Jul  5 16:38 snappy-1.0.4.1-libsnappyjava.so
        -rwxr-xr-x  1 cassandra       cassandra        48432 Jul  5 16:35 snappy-1.0.5-libsnappyjava.so
        

        The only thing I haven't tried is to update our java version to a later 1.6.x release or go to 1.7.x or even try OpenJDK as this created some issues with other softwares we had since the server was coming up but queries to the keyspaces were coming back as errors or unknown keyspaces...

        Let me know if you need more information, I'll be glad to help out.

        Thanks guys !

        Show
        Patrick Monfette added a comment - - edited I believe this fix (going to snappy 1.0.5) broke Cassandra on CentOS 5 for us. We're using the RPM package. I upgraded from Cassandra 1.2.5 (which was using snappy 1.0.4) and I couldn't get 1.2.6 to start up properly and I had to rollback to 1.2.5. Here's the error I was getting when starting Cassandra 1.2.6 after the upgrade. ERROR [SSTableBatchOpen:5] 2013-07-05 16:35:22,466 CassandraDaemon.java (line 192) Exception in thread Thread [SSTableBatchOpen:5,5,main] java.lang.RuntimeException: Cannot create CompressionParameters for stored parameters at org.apache.cassandra.io.compress.CompressionMetadata.<init>(CompressionMetadata.java:99) at org.apache.cassandra.io.compress.CompressionMetadata.create(CompressionMetadata.java:63) at org.apache.cassandra.io.util.CompressedSegmentedFile$Builder.complete(CompressedSegmentedFile.java:51) at org.apache.cassandra.io.sstable.SSTableReader.load(SSTableReader.java:411) at org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:201) at org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:154) at org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:241) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang. Thread .run( Thread .java:662) Caused by: org.apache.cassandra.exceptions.ConfigurationException: SnappyCompressor.create() threw an error: java.lang.NoClassDefFoundError Could not initialize class org.xerial.snappy.Snappy at org.apache.cassandra.io.compress.CompressionParameters.createCompressor(CompressionParameters.java:179) at org.apache.cassandra.io.compress.CompressionParameters.<init>(CompressionParameters.java:71) at org.apache.cassandra.io.compress.CompressionMetadata.<init>(CompressionMetadata.java:95) ... 12 more Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.cassandra.io.compress.CompressionParameters.createCompressor(CompressionParameters.java:156) ... 14 more Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.xerial.snappy.Snappy at org.apache.cassandra.io.compress.SnappyCompressor.create(SnappyCompressor.java:45) ... 19 more I did try to implement the following documented fix that seemed related to our issue but it did not work: http://www.datastax.com/docs/1.0/troubleshooting/index#snappy Furthermore, I suspect this is not the exact same problem since 1.2.5 was working perfectly fine for us without the above fix. We only did an update of the Cassandra package to 1.2.6, diffed and merged the yaml config file and tried to start it back up, like all the other previous upgrades we did as version 1.2.x came out. I also fully updated all server packages in case it had something to do with an old library somwehere else or something but it did not work either. We're running the latest CentOS 5.9, 64 bits, fully updated. We're running java 1.6.0 from Sun (not OpenJDK) java version "1.6.0_26" Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode) Here is the content of my /tmp folder on the server (those get created when I start up Cassandra. The 1.0.5 is the one that got created when I was trying to start up Cassandra 1.2.6. It seems quite small compared to version 1.0.4 (which was created by version 1.2.5). -rwxr-xr-x 1 cassandra cassandra 991112 Jul 5 16:38 snappy-1.0.4.1-libsnappyjava.so -rwxr-xr-x 1 cassandra cassandra 48432 Jul 5 16:35 snappy-1.0.5-libsnappyjava.so The only thing I haven't tried is to update our java version to a later 1.6.x release or go to 1.7.x or even try OpenJDK as this created some issues with other softwares we had since the server was coming up but queries to the keyspaces were coming back as errors or unknown keyspaces... Let me know if you need more information, I'll be glad to help out. Thanks guys !
        Hide
        Patrick Monfette added a comment - - edited

        Me again, I believe I found the issue, it requires a much too recent glibc version than what is available for CentOS 5. Only CentOS 6 seems to have it for now.

         INFO 03:32:04,175 Not using multi-threaded compaction
        java.lang.reflect.InvocationTargetException
                at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
                at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                at java.lang.reflect.Method.invoke(Method.java:597)
                at org.xerial.snappy.SnappyLoader.loadNativeLibrary(SnappyLoader.java:322)
                at org.xerial.snappy.SnappyLoader.load(SnappyLoader.java:229)
                at org.xerial.snappy.Snappy.<clinit>(Snappy.java:48)
                at org.apache.cassandra.io.compress.SnappyCompressor.create(SnappyCompressor.java:45)
                at org.apache.cassandra.io.compress.SnappyCompressor.isAvailable(SnappyCompressor.java:55)
                at org.apache.cassandra.io.compress.SnappyCompressor.<clinit>(SnappyCompressor.java:37)
                at org.apache.cassandra.config.CFMetaData.<clinit>(CFMetaData.java:82)
                at org.apache.cassandra.config.KSMetaData.systemKeyspace(KSMetaData.java:81)
                at org.apache.cassandra.config.DatabaseDescriptor.loadYaml(DatabaseDescriptor.java:468)
                at org.apache.cassandra.config.DatabaseDescriptor.<clinit>(DatabaseDescriptor.java:123)
                at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:211)
                at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:441)
                at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:484)
        Caused by: java.lang.UnsatisfiedLinkError: /tmp/snappy-1.0.5-libsnappyjava.so: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /tmp/snappy-1.0.5-libsnappyjava.so)
                at java.lang.ClassLoader$NativeLibrary.load(Native Method)
                at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1807)
                at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1703)
                at java.lang.Runtime.load0(Runtime.java:770)
                at java.lang.System.load(System.java:1003)
                at org.xerial.snappy.SnappyNativeLoader.load(SnappyNativeLoader.java:39)
                ... 17 more
         WARN 03:32:04,200 Cannot initialize native Snappy library. Compression on new tables will be disabled.
        

        Hopefully this will help you fix this issue.

        Thanks.

        Show
        Patrick Monfette added a comment - - edited Me again, I believe I found the issue, it requires a much too recent glibc version than what is available for CentOS 5. Only CentOS 6 seems to have it for now. INFO 03:32:04,175 Not using multi-threaded compaction java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.xerial.snappy.SnappyLoader.loadNativeLibrary(SnappyLoader.java:322) at org.xerial.snappy.SnappyLoader.load(SnappyLoader.java:229) at org.xerial.snappy.Snappy.<clinit>(Snappy.java:48) at org.apache.cassandra.io.compress.SnappyCompressor.create(SnappyCompressor.java:45) at org.apache.cassandra.io.compress.SnappyCompressor.isAvailable(SnappyCompressor.java:55) at org.apache.cassandra.io.compress.SnappyCompressor.<clinit>(SnappyCompressor.java:37) at org.apache.cassandra.config.CFMetaData.<clinit>(CFMetaData.java:82) at org.apache.cassandra.config.KSMetaData.systemKeyspace(KSMetaData.java:81) at org.apache.cassandra.config.DatabaseDescriptor.loadYaml(DatabaseDescriptor.java:468) at org.apache.cassandra.config.DatabaseDescriptor.<clinit>(DatabaseDescriptor.java:123) at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:211) at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:441) at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:484) Caused by: java.lang.UnsatisfiedLinkError: /tmp/snappy-1.0.5-libsnappyjava.so: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /tmp/snappy-1.0.5-libsnappyjava.so) at java.lang. ClassLoader $NativeLibrary.load(Native Method) at java.lang. ClassLoader .loadLibrary0( ClassLoader .java:1807) at java.lang. ClassLoader .loadLibrary( ClassLoader .java:1703) at java.lang. Runtime .load0( Runtime .java:770) at java.lang. System .load( System .java:1003) at org.xerial.snappy.SnappyNativeLoader.load(SnappyNativeLoader.java:39) ... 17 more WARN 03:32:04,200 Cannot initialize native Snappy library. Compression on new tables will be disabled. Hopefully this will help you fix this issue. Thanks.
        Hide
        Patrick Monfette added a comment -

        Here's what CentOS 5 seems to provide (very latest update), very close but not 3.4.9

        rpm -q --provides libstdc++

        libstdc++ = 4.1.1-52.el5
        libstdc++.so.6()(64bit)
        libstdc++.so.6(CXXABI_1.3)(64bit)
        libstdc++.so.6(CXXABI_1.3.1)(64bit)
        libstdc++.so.6(GLIBCXX_3.4)(64bit)
        libstdc++.so.6(GLIBCXX_3.4.1)(64bit)
        libstdc++.so.6(GLIBCXX_3.4.2)(64bit)
        libstdc++.so.6(GLIBCXX_3.4.3)(64bit)
        libstdc++.so.6(GLIBCXX_3.4.4)(64bit)
        libstdc++.so.6(GLIBCXX_3.4.5)(64bit)
        libstdc++.so.6(GLIBCXX_3.4.6)(64bit)
        libstdc++.so.6(GLIBCXX_3.4.7)(64bit)
        libstdc++.so.6(GLIBCXX_3.4.8)(64bit)
        libstdc++ = 4.1.2-54.el5
        
        Show
        Patrick Monfette added a comment - Here's what CentOS 5 seems to provide (very latest update), very close but not 3.4.9 rpm -q --provides libstdc++ libstdc++ = 4.1.1-52.el5 libstdc++.so.6()(64bit) libstdc++.so.6(CXXABI_1.3)(64bit) libstdc++.so.6(CXXABI_1.3.1)(64bit) libstdc++.so.6(GLIBCXX_3.4)(64bit) libstdc++.so.6(GLIBCXX_3.4.1)(64bit) libstdc++.so.6(GLIBCXX_3.4.2)(64bit) libstdc++.so.6(GLIBCXX_3.4.3)(64bit) libstdc++.so.6(GLIBCXX_3.4.4)(64bit) libstdc++.so.6(GLIBCXX_3.4.5)(64bit) libstdc++.so.6(GLIBCXX_3.4.6)(64bit) libstdc++.so.6(GLIBCXX_3.4.7)(64bit) libstdc++.so.6(GLIBCXX_3.4.8)(64bit) libstdc++ = 4.1.2-54.el5
        Hide
        Jonathan Ellis added a comment -

        I imagine you can just drop the old 1.0.4 library back in.

        Show
        Jonathan Ellis added a comment - I imagine you can just drop the old 1.0.4 library back in.
        Hide
        Patrick Monfette added a comment -

        Hello,

        is there a fix for this issue for an upcoming release or is support for CentOS/RHEL 5 dropped starting with version 1.2.6 ?

        I saw Jonathan's comment but I definitely would prefer not to go this way since we are using the rpm package, I would prefer that everything remains as distributed/packaged.

        Should I open up a new bug for this instead of commenting here ?

        Thanks.

        Show
        Patrick Monfette added a comment - Hello, is there a fix for this issue for an upcoming release or is support for CentOS/RHEL 5 dropped starting with version 1.2.6 ? I saw Jonathan's comment but I definitely would prefer not to go this way since we are using the rpm package, I would prefer that everything remains as distributed/packaged. Should I open up a new bug for this instead of commenting here ? Thanks.
        Hide
        Jonathan Ellis added a comment -

        Just to be clear, if we had known 1.0.5 would break RHEL5 we would have waited for 2.0. But since we didn't find out until 1.2.6 was out in the wild, I think you can consider RHEL5 support dropped in Apache Cassandra, since reverting to the older version would break OS X users.

        However, I note that DataStax Enterprise 3.1 (based on 1.2.x) still packages the old Snappy (and does not support OS X).

        Show
        Jonathan Ellis added a comment - Just to be clear, if we had known 1.0.5 would break RHEL5 we would have waited for 2.0. But since we didn't find out until 1.2.6 was out in the wild, I think you can consider RHEL5 support dropped in Apache Cassandra, since reverting to the older version would break OS X users. However, I note that DataStax Enterprise 3.1 (based on 1.2.x) still packages the old Snappy (and does not support OS X).

          People

          • Assignee:
            Yuki Morishita
            Reporter:
            Colin Taylor
            Reviewer:
            Sylvain Lebresne
          • Votes:
            0 Vote for this issue
            Watchers:
            9 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development