[jira] [Created] (CASSANDRA-8395) typo in sstablerepairedset
David Sauer created CASSANDRA-8395: -- Summary: typo in sstablerepairedset Key: CASSANDRA-8395 URL: https://issues.apache.org/jira/browse/CASSANDRA-8395 Project: Cassandra Issue Type: Bug Reporter: David Sauer Priority: Trivial -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8395) typo in sstablerepairedset
[ https://issues.apache.org/jira/browse/CASSANDRA-8395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Sauer updated CASSANDRA-8395: --- Attachment: 0001-fixed-typo.patch > typo in sstablerepairedset > -- > > Key: CASSANDRA-8395 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8395 > Project: Cassandra > Issue Type: Bug >Reporter: David Sauer >Priority: Trivial > Attachments: 0001-fixed-typo.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-6285) compaction failing
David Sauer created CASSANDRA-6285: -- Summary: compaction failing Key: CASSANDRA-6285 URL: https://issues.apache.org/jira/browse/CASSANDRA-6285 Project: Cassandra Issue Type: Bug Environment: 4 nodes, shortly updated from 1.2.11 to 2.0.2 Reporter: David Sauer After altering everything to LCS the table OpsCenter.rollups60 amd one other none OpsCenter-Table got stuck with everything hanging around in L0. The compaction started and ran until the logs showed this: ERROR [CompactionExecutor:111] 2013-11-01 19:14:53,865 CassandraDaemon.java (line 187) Exception in thread Thread[CompactionExecutor:111,1,RMI Runtime] java.lang.RuntimeException: Last written key DecoratedKey(1326283851463420237, 37382e34362e3132382e3139382d6a7576616c69735f6e6f72785f696e6465785f323031335f31305f30382d63616368655f646f63756d656e74736c6f6f6b75702d676574426c6f6f6d46696c746572537061636555736564) >= current key DecoratedKey(954210699457429663, 37382e34362e3132382e3139382d6a7576616c69735f6e6f72785f696e6465785f323031335f31305f30382d63616368655f646f63756d656e74736c6f6f6b75702d676574546f74616c4469736b5370616365557365640b0f) writing into /var/lib/cassandra/data/OpsCenter/rollups60/OpsCenter-rollups60-tmp-jb-58656-Data.db at org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:141) at org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:164) at org.apache.cassandra.db.compaction.CompactionTask.runWith(CompactionTask.java:160) 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$6.runMayThrow(CompactionManager.java:296) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) 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) Moving back to STC worked to keep the compactions running. Especialy my own Table i would like to move to LCS. After a major compaction with STC the move to LCS fails with the same Exception. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CASSANDRA-6285) LCS compaction failing
[ https://issues.apache.org/jira/browse/CASSANDRA-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Sauer updated CASSANDRA-6285: --- Summary: LCS compaction failing (was: compaction failing) > LCS compaction failing > -- > > Key: CASSANDRA-6285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6285 > Project: Cassandra > Issue Type: Bug > Environment: 4 nodes, shortly updated from 1.2.11 to 2.0.2 >Reporter: David Sauer > > After altering everything to LCS the table OpsCenter.rollups60 amd one other > none OpsCenter-Table got stuck with everything hanging around in L0. > The compaction started and ran until the logs showed this: > ERROR [CompactionExecutor:111] 2013-11-01 19:14:53,865 CassandraDaemon.java > (line 187) Exception in thread Thread[CompactionExecutor:111,1,RMI Runtime] > java.lang.RuntimeException: Last written key > DecoratedKey(1326283851463420237, > 37382e34362e3132382e3139382d6a7576616c69735f6e6f72785f696e6465785f323031335f31305f30382d63616368655f646f63756d656e74736c6f6f6b75702d676574426c6f6f6d46696c746572537061636555736564) > >= current key DecoratedKey(954210699457429663, > 37382e34362e3132382e3139382d6a7576616c69735f6e6f72785f696e6465785f323031335f31305f30382d63616368655f646f63756d656e74736c6f6f6b75702d676574546f74616c4469736b5370616365557365640b0f) > writing into > /var/lib/cassandra/data/OpsCenter/rollups60/OpsCenter-rollups60-tmp-jb-58656-Data.db > at > org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:141) > at > org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:164) > at > org.apache.cassandra.db.compaction.CompactionTask.runWith(CompactionTask.java:160) > 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$6.runMayThrow(CompactionManager.java:296) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > 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) > Moving back to STC worked to keep the compactions running. > Especialy my own Table i would like to move to LCS. > After a major compaction with STC the move to LCS fails with the same > Exception. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CASSANDRA-6285) LCS compaction failing with Exception
[ https://issues.apache.org/jira/browse/CASSANDRA-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Sauer updated CASSANDRA-6285: --- Summary: LCS compaction failing with Exception (was: LCS compaction failing) > LCS compaction failing with Exception > - > > Key: CASSANDRA-6285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6285 > Project: Cassandra > Issue Type: Bug > Environment: 4 nodes, shortly updated from 1.2.11 to 2.0.2 >Reporter: David Sauer > > After altering everything to LCS the table OpsCenter.rollups60 amd one other > none OpsCenter-Table got stuck with everything hanging around in L0. > The compaction started and ran until the logs showed this: > ERROR [CompactionExecutor:111] 2013-11-01 19:14:53,865 CassandraDaemon.java > (line 187) Exception in thread Thread[CompactionExecutor:111,1,RMI Runtime] > java.lang.RuntimeException: Last written key > DecoratedKey(1326283851463420237, > 37382e34362e3132382e3139382d6a7576616c69735f6e6f72785f696e6465785f323031335f31305f30382d63616368655f646f63756d656e74736c6f6f6b75702d676574426c6f6f6d46696c746572537061636555736564) > >= current key DecoratedKey(954210699457429663, > 37382e34362e3132382e3139382d6a7576616c69735f6e6f72785f696e6465785f323031335f31305f30382d63616368655f646f63756d656e74736c6f6f6b75702d676574546f74616c4469736b5370616365557365640b0f) > writing into > /var/lib/cassandra/data/OpsCenter/rollups60/OpsCenter-rollups60-tmp-jb-58656-Data.db > at > org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:141) > at > org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:164) > at > org.apache.cassandra.db.compaction.CompactionTask.runWith(CompactionTask.java:160) > 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$6.runMayThrow(CompactionManager.java:296) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > 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) > Moving back to STC worked to keep the compactions running. > Especialy my own Table i would like to move to LCS. > After a major compaction with STC the move to LCS fails with the same > Exception. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6285) compaction failing
[ https://issues.apache.org/jira/browse/CASSANDRA-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13811919#comment-13811919 ] David Sauer commented on CASSANDRA-6285: After removing all the Data from the OpsCenters Keyspace (and using LCS) and collectiong new Data for a night, the command nodetool compact OpsCenter rollups60 failed with this Exception: Error occurred during compaction java.util.concurrent.ExecutionException: java.lang.RuntimeException: Last written key DecoratedKey(-6663228376520744598, 37382e34362e3132382e3139382d6a7576616c69735f6e6f72785f6c6f6767696e672d706572666f726d616e63655f67726f757065642d67657452656164436f756e740b0f00010009726f6c6c75707336) >= current key DecoratedKey(-6896470603826733036, 37382e34362e3132382e3139382d6d65646970726569735f7365617263685f696e6465785f323031335f31305f30382d6d756c7469776f7264735f70686f6e656d732d6765744c69766553535461626c65436f756e74) writing into /var/lib/cassandra/data/OpsCenter/rollups60/OpsCenter-rollups60-tmp-jb-14-Data.db at java.util.concurrent.FutureTask.report(FutureTask.java:122) at java.util.concurrent.FutureTask.get(FutureTask.java:188) at org.apache.cassandra.db.compaction.CompactionManager.performMaximal(CompactionManager.java:281) at org.apache.cassandra.db.ColumnFamilyStore.forceMajorCompaction(ColumnFamilyStore.java:1845) at org.apache.cassandra.service.StorageService.forceKeyspaceCompaction(StorageService.java:2167) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75) at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237) at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487) at javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848) at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322) at sun.rmi.transport.Transport$1.run(Transport.java:177) at sun.rmi.transport.Transport$1.run(Transport.java:174) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:173) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670) 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) Caused by: java.lang.RuntimeException: Last written key DecoratedKey(-6663228376520744598, 37382e34362e3132382e3139382d6a7576616c69735f6e6f72785f6c6f6767696e672d706572666f726d616e63655f67726f757065642d67657452656164436f756e740b0f00010009726f6c6c75707336) >= current key DecoratedKey(-6896470603826733036, 37382e34362e3132382e3139382d6d65646970726569735f7365617263685f696e6465785f323031335f31305f30382d6d756c7469776f7264735f70686f6e656d732d6765744c69766553535461626c65436f756e74) writing into /var
[jira] [Created] (CASSANDRA-5275) Error validating row DecoratedKey(..., ...)
David Sauer created CASSANDRA-5275: -- Summary: Error validating row DecoratedKey(..., ...) Key: CASSANDRA-5275 URL: https://issues.apache.org/jira/browse/CASSANDRA-5275 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.1 Environment: 3 nodes, each 22GB, using internode ssl Reporter: David Sauer after upgrading from 1.1.9 to 1.2.1 this happend many times. WARN [CompactionExecutor:699] 2013-02-19 19:31:18,940 OutputHandler.java (line 57) Non-fatal error reading row (stacktrace follows) java.lang.RuntimeException: Error validating row DecoratedKey(21728933070208571032820692349722239108, 32303133303132382d323133322d6c6f6767696e67) at org.apache.cassandra.io.sstable.SSTableIdentityIterator.getColumnFamilyWithColumns(SSTableIdentityIterator.java:244) at org.apache.cassandra.db.compaction.PrecompactedRow.merge(PrecompactedRow.java:109) at org.apache.cassandra.db.compaction.PrecompactedRow.(PrecompactedRow.java:93) at org.apache.cassandra.db.compaction.CompactionController.getCompactedRow(CompactionController.java:162) at org.apache.cassandra.db.compaction.CompactionController.getCompactedRow(CompactionController.java:168) at org.apache.cassandra.db.compaction.Scrubber.scrub(Scrubber.java:173) at org.apache.cassandra.db.compaction.CompactionManager.scrubOne(CompactionManager.java:544) at org.apache.cassandra.db.compaction.CompactionManager.doScrub(CompactionManager.java:533) at org.apache.cassandra.db.compaction.CompactionManager.access$400(CompactionManager.java:75) at org.apache.cassandra.db.compaction.CompactionManager$3.perform(CompactionManager.java:270) at org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:240) 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:722) Caused by: org.apache.cassandra.db.marshal.MarshalException: String didn't validate. at org.apache.cassandra.db.marshal.UTF8Type.validate(UTF8Type.java:65) at org.apache.cassandra.db.Column.validateFields(Column.java:292) at org.apache.cassandra.db.ColumnFamily.validateColumnFields(ColumnFamily.java:377) at org.apache.cassandra.io.sstable.SSTableIdentityIterator.getColumnFamilyWithColumns(SSTableIdentityIterator.java:240) ... 15 more WARN [CompactionExecutor:699] 2013-02-19 19:31:18,941 OutputHandler.java (line 52) Row at 2464413 is unreadable; skipping to next -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5275) Error validating row DecoratedKey(..., ...)
[ https://issues.apache.org/jira/browse/CASSANDRA-5275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13582701#comment-13582701 ] David Sauer commented on CASSANDRA-5275: now a "block" of these exception got logged while running "nodetool scrub" > Error validating row DecoratedKey(..., ...) > --- > > Key: CASSANDRA-5275 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5275 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.2.1 > Environment: 3 nodes, each 22GB, using internode ssl >Reporter: David Sauer > > after upgrading from 1.1.9 to 1.2.1 this happend many times. > WARN [CompactionExecutor:699] 2013-02-19 19:31:18,940 OutputHandler.java > (line 57) Non-fatal error reading row (stacktrace follows) > java.lang.RuntimeException: Error validating row > DecoratedKey(21728933070208571032820692349722239108, > 32303133303132382d323133322d6c6f6767696e67) > at > org.apache.cassandra.io.sstable.SSTableIdentityIterator.getColumnFamilyWithColumns(SSTableIdentityIterator.java:244) > at > org.apache.cassandra.db.compaction.PrecompactedRow.merge(PrecompactedRow.java:109) > at > org.apache.cassandra.db.compaction.PrecompactedRow.(PrecompactedRow.java:93) > at > org.apache.cassandra.db.compaction.CompactionController.getCompactedRow(CompactionController.java:162) > at > org.apache.cassandra.db.compaction.CompactionController.getCompactedRow(CompactionController.java:168) > at org.apache.cassandra.db.compaction.Scrubber.scrub(Scrubber.java:173) > at > org.apache.cassandra.db.compaction.CompactionManager.scrubOne(CompactionManager.java:544) > at > org.apache.cassandra.db.compaction.CompactionManager.doScrub(CompactionManager.java:533) > at > org.apache.cassandra.db.compaction.CompactionManager.access$400(CompactionManager.java:75) > at > org.apache.cassandra.db.compaction.CompactionManager$3.perform(CompactionManager.java:270) > at > org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:240) > 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:722) > Caused by: org.apache.cassandra.db.marshal.MarshalException: String didn't > validate. > at org.apache.cassandra.db.marshal.UTF8Type.validate(UTF8Type.java:65) > at org.apache.cassandra.db.Column.validateFields(Column.java:292) > at > org.apache.cassandra.db.ColumnFamily.validateColumnFields(ColumnFamily.java:377) > at > org.apache.cassandra.io.sstable.SSTableIdentityIterator.getColumnFamilyWithColumns(SSTableIdentityIterator.java:240) > ... 15 more > WARN [CompactionExecutor:699] 2013-02-19 19:31:18,941 OutputHandler.java > (line 52) Row at 2464413 is unreadable; skipping to next -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5352) PreparedStatements get mixed up between Keyspaces
David Sauer created CASSANDRA-5352: -- Summary: PreparedStatements get mixed up between Keyspaces Key: CASSANDRA-5352 URL: https://issues.apache.org/jira/browse/CASSANDRA-5352 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.2 Reporter: David Sauer I found this behavior while running the same application using two different keyspaces connected to the same node. The prepared statements uses the keyspace that was set while the statement was perpared (public final CFDefinition cfDef). When reusing the Statement only the cql-query is used to create a key and the keyspace is ignored. When the same query is prepared and used for two different Keyspaces the wrong keyspace can be used. The fix is not to ignore the keyspace when reusing the statement. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5352) PreparedStatements get mixed up between Keyspaces
[ https://issues.apache.org/jira/browse/CASSANDRA-5352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Sauer updated CASSANDRA-5352: --- Attachment: CassandraServerCql3Test.java the testcase for select querys > PreparedStatements get mixed up between Keyspaces > - > > Key: CASSANDRA-5352 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5352 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.2.2 >Reporter: David Sauer > Attachments: CassandraServerCql3Test.java > > > I found this behavior while running the same application using two different > keyspaces connected to the same node. > The prepared statements uses the keyspace that was set while the statement > was perpared (public final CFDefinition cfDef). > When reusing the Statement only the cql-query is used to create a key and the > keyspace is ignored. When the same query is prepared and used for two > different Keyspaces the wrong keyspace can be used. > The fix is not to ignore the keyspace when reusing the statement. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5352) PreparedStatements get mixed up between Keyspaces
[ https://issues.apache.org/jira/browse/CASSANDRA-5352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Sauer updated CASSANDRA-5352: --- Attachment: patch.txt change to involve the keyspace while creating the key for statment storage > PreparedStatements get mixed up between Keyspaces > - > > Key: CASSANDRA-5352 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5352 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.2.2 >Reporter: David Sauer > Attachments: CassandraServerCql3Test.java, patch.txt > > > I found this behavior while running the same application using two different > keyspaces connected to the same node. > The prepared statements uses the keyspace that was set while the statement > was perpared (public final CFDefinition cfDef). > When reusing the Statement only the cql-query is used to create a key and the > keyspace is ignored. When the same query is prepared and used for two > different Keyspaces the wrong keyspace can be used. > The fix is not to ignore the keyspace when reusing the statement. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira