[jira] [Updated] (CASSANDRA-4494) nodetool can't work at all !
[
https://issues.apache.org/jira/browse/CASSANDRA-4494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
sunjian updated CASSANDRA-4494:
---
Description:
1. download cassandra 1.1.3 , then start with {cassandra}/bin/cassandra -pf
2. cd to bin , call nodetool as ./nodetool -h localhost ring
3. console returned : failed to connect to 'localhost:7199' : connection refused
BUT ,
at the same centos , all was ok before (1.1.2) .
PS:
cassandra-cli/cqlsh works well (1.1.3)
--
update:
even if add the following in cassandra-env.sh , connection refused as well :
JVM_OPTS=$JVM_OPTS -Djava.rmi.server.hostname=10.10.30.11
was:
1. download cassandra 1.1.3 , then start with {cassandra}/bin/cassandra -pf
2. cd to bin , call nodetool as ./nodetool -h localhost ring
3. console returned : failed to connect to 'localhost:7199' : connection refused
BUT ,
at the same centos , all was ok before (1.1.2) .
PS:
cassandra-cli/cqlsh works well (1.1.3)
nodetool can't work at all !
Key: CASSANDRA-4494
URL: https://issues.apache.org/jira/browse/CASSANDRA-4494
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.1.3
Environment: centos 64bit
Reporter: sunjian
Priority: Critical
Fix For: 1.1.3
1. download cassandra 1.1.3 , then start with {cassandra}/bin/cassandra -pf
2. cd to bin , call nodetool as ./nodetool -h localhost ring
3. console returned : failed to connect to 'localhost:7199' : connection
refused
BUT ,
at the same centos , all was ok before (1.1.2) .
PS:
cassandra-cli/cqlsh works well (1.1.3)
--
update:
even if add the following in cassandra-env.sh , connection refused as well :
JVM_OPTS=$JVM_OPTS -Djava.rmi.server.hostname=10.10.30.11
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4495) Don't tie client side use of AbstractType to JDBC
Sylvain Lebresne created CASSANDRA-4495: --- Summary: Don't tie client side use of AbstractType to JDBC Key: CASSANDRA-4495 URL: https://issues.apache.org/jira/browse/CASSANDRA-4495 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Priority: Minor Fix For: 1.2 We currently expose the AbstractType to java clients that want to reuse them though the cql.jdbc.* classes. I think this shouldn't be tied to the JDBC standard. JDBC was make for SQL DB, which Cassandra is not (CQL is not SQL and will never be). Typically, there is a fair amount of the JDBC standard that cannot be implemented with C*, and there is a number of specificity of C* that are not in JDBC (typically the set and maps collections). So I propose to extract simple type classes with just a compose and decompose method (but without ties to jdbc, which would allow all the jdbc specific method those types have) in the purpose of exporting that in a separate jar for clients (we could put that in a org.apache.cassandra.type package for instance). We could then deprecate the jdbc classes with basically the same schedule than CQL2. Let me note that this is *not* saying there shouldn't be a JDBC driver for Cassandra. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4400) Correctly catch exception when Snappy cannot be loaded
[
https://issues.apache.org/jira/browse/CASSANDRA-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13429065#comment-13429065
]
Sylvain Lebresne commented on CASSANDRA-4400:
-
As explain above, the large stack trace is thrown by the Snappy library itself,
so until they fix that there is nothing we can do about it, sorry.
Correctly catch exception when Snappy cannot be loaded
--
Key: CASSANDRA-4400
URL: https://issues.apache.org/jira/browse/CASSANDRA-4400
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.1
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 1.1.3
Attachments: 4400.txt
From the mailing list, on C* 1.1.1:
{noformat}
INFO 14:22:07,600 Global memtable threshold is enabled at 35MB
java.lang.reflect.InvocationTargetException
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:616)
at
org.xerial.snappy.SnappyLoader.loadNativeLibrary(SnappyLoader.java:317)
at org.xerial.snappy.SnappyLoader.load(SnappyLoader.java:219)
at org.xerial.snappy.Snappy.clinit(Snappy.java:44)
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:76)
at
org.apache.cassandra.config.KSMetaData.systemKeyspace(KSMetaData.java:79)
at
org.apache.cassandra.config.DatabaseDescriptor.loadYaml(DatabaseDescriptor.java:439)
at
org.apache.cassandra.config.DatabaseDescriptor.clinit(DatabaseDescriptor.java:118)
at
org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:126)
at
org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:353)
at
org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:106)
Caused by: java.lang.UnsatisfiedLinkError: no snappyjava in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1681)
at java.lang.Runtime.loadLibrary0(Runtime.java:840)
at java.lang.System.loadLibrary(System.java:1047)
at
org.xerial.snappy.SnappyNativeLoader.loadLibrary(SnappyNativeLoader.java:52)
... 17 more
ERROR 14:22:09,934 Exception encountered during startup
org.xerial.snappy.SnappyError: [FAILED_TO_LOAD_NATIVE_LIBRARY] null
at org.xerial.snappy.SnappyLoader.load(SnappyLoader.java:229)
at org.xerial.snappy.Snappy.clinit(Snappy.java:44)
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:76)
at
org.apache.cassandra.config.KSMetaData.systemKeyspace(KSMetaData.java:79)
at
org.apache.cassandra.config.DatabaseDescriptor.loadYaml(DatabaseDescriptor.java:439)
at
org.apache.cassandra.config.DatabaseDescriptor.clinit(DatabaseDescriptor.java:118)
at
org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:126)
at
org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:353)
at
org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:106)
org.xerial.snappy.SnappyError: [FAILED_TO_LOAD_NATIVE_LIBRARY] null
at org.xerial.snappy.SnappyLoader.load(SnappyLoader.java:229)
at org.xerial.snappy.Snappy.clinit(Snappy.java:44)
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:76)
at
org.apache.cassandra.config.KSMetaData.systemKeyspace(KSMetaData.java:79)
at
org.apache.cassandra.config.DatabaseDescriptor.loadYaml(DatabaseDescriptor.java:439)
at
[jira] [Commented] (CASSANDRA-4494) nodetool can't work at all !
[
https://issues.apache.org/jira/browse/CASSANDRA-4494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13429071#comment-13429071
]
Lloyd Oliver commented on CASSANDRA-4494:
-
Confirmed.
1.1.2 nodetool works perfectly
1.1.3 nodetool throws back 'connection refused' error
setting the JVM_OPTS hostname in cassandra-env.sh has no effect.
connection via 'localhost', server hostname, or server IP address all return
the same result.
connection to remote 1.1.3 host from 1.1.3 host fails.
Connection to remote 1.1.2 host from 1.1.3 host works fine.
Connection from 1.1.2 host to remote 1.1.3 host fails.
restarting the node has no effect.
replacing nodetool with file from previous version (1.1.2) has no effect.
CentOS release 5.8 (Final) x86_64
nodetool can't work at all !
Key: CASSANDRA-4494
URL: https://issues.apache.org/jira/browse/CASSANDRA-4494
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.1.3
Environment: centos 64bit
Reporter: sunjian
Priority: Critical
Fix For: 1.1.3
1. download cassandra 1.1.3 , then start with {cassandra}/bin/cassandra -pf
2. cd to bin , call nodetool as ./nodetool -h localhost ring
3. console returned : failed to connect to 'localhost:7199' : connection
refused
BUT ,
at the same centos , all was ok before (1.1.2) .
PS:
cassandra-cli/cqlsh works well (1.1.3)
--
update:
even if add the following in cassandra-env.sh , connection refused as well :
JVM_OPTS=$JVM_OPTS -Djava.rmi.server.hostname=10.10.30.11
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4494) nodetool can't work at all !
[
https://issues.apache.org/jira/browse/CASSANDRA-4494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13429137#comment-13429137
]
sunjian commented on CASSANDRA-4494:
there should be some official tips to tell us is it a bug or not ? if a bug ,
it should be fixed immediately , or show some resolutions officially .
nodetool can't work at all !
Key: CASSANDRA-4494
URL: https://issues.apache.org/jira/browse/CASSANDRA-4494
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.1.3
Environment: centos 64bit
Reporter: sunjian
Priority: Critical
Fix For: 1.1.3
1. download cassandra 1.1.3 , then start with {cassandra}/bin/cassandra -pf
2. cd to bin , call nodetool as ./nodetool -h localhost ring
3. console returned : failed to connect to 'localhost:7199' : connection
refused
BUT ,
at the same centos , all was ok before (1.1.2) .
PS:
cassandra-cli/cqlsh works well (1.1.3)
--
update:
even if add the following in cassandra-env.sh , connection refused as well :
JVM_OPTS=$JVM_OPTS -Djava.rmi.server.hostname=10.10.30.11
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3680) Add Support for Composite Secondary Indexes
[ https://issues.apache.org/jira/browse/CASSANDRA-3680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13429141#comment-13429141 ] Sylvain Lebresne commented on CASSANDRA-3680: - You're right. Pushed a rebased and fixed version at https://github.com/pcmanus/cassandra/commits/3680-3. Add Support for Composite Secondary Indexes --- Key: CASSANDRA-3680 URL: https://issues.apache.org/jira/browse/CASSANDRA-3680 Project: Cassandra Issue Type: Sub-task Reporter: T Jake Luciani Assignee: Sylvain Lebresne Labels: cql3, secondary_index Fix For: 1.2 Attachments: 0001-Secondary-indexes-on-composite-columns.txt CASSANDRA-2474 and CASSANDRA-3647 add the ability to transpose wide rows differently, for efficiency and functionality secondary index api needs to be altered to allow composite indexes. I think this will require the IndexManager api to have a maybeIndex(ByteBuffer column) method that SS can call and implement a PerRowSecondaryIndex per column, break the composite into parts and index specific bits, also including the base rowkey. Then a search against a TRANSPOSED row or DOCUMENT will be possible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-4494) nodetool can't work at all !
[
https://issues.apache.org/jira/browse/CASSANDRA-4494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne reassigned CASSANDRA-4494:
---
Assignee: paul cannon
nodetool can't work at all !
Key: CASSANDRA-4494
URL: https://issues.apache.org/jira/browse/CASSANDRA-4494
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.1.3
Environment: centos 64bit
Reporter: sunjian
Assignee: paul cannon
Priority: Critical
Fix For: 1.1.3
1. download cassandra 1.1.3 , then start with {cassandra}/bin/cassandra -pf
2. cd to bin , call nodetool as ./nodetool -h localhost ring
3. console returned : failed to connect to 'localhost:7199' : connection
refused
BUT ,
at the same centos , all was ok before (1.1.2) .
PS:
cassandra-cli/cqlsh works well (1.1.3)
--
update:
even if add the following in cassandra-env.sh , connection refused as well :
JVM_OPTS=$JVM_OPTS -Djava.rmi.server.hostname=10.10.30.11
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4494) nodetool can't work at all !
[
https://issues.apache.org/jira/browse/CASSANDRA-4494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13429155#comment-13429155
]
Sylvain Lebresne commented on CASSANDRA-4494:
-
I don't have a centos to test, but I do get the same on macosx (but not on
ubuntu for instance). More precisely, the error is:
{noformat}
./bin/../conf/cassandra-env.sh: line 180: syntax error near unexpected token `['
./bin/../conf/cassandra-env.sh: line 180: `startswith () [ ${1#$2} != $1 ]'
{noformat}
The reason this breaks JMX is just that the JMX port is not set at that point
of the script and the script likely exit on the error. It seems there is some
shell incompatibility again.
While we fix that, a workaround could be to edit the cassandra-env.sh to
comment the incriminated line.
nodetool can't work at all !
Key: CASSANDRA-4494
URL: https://issues.apache.org/jira/browse/CASSANDRA-4494
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.1.3
Environment: centos 64bit
Reporter: sunjian
Priority: Critical
Fix For: 1.1.3
1. download cassandra 1.1.3 , then start with {cassandra}/bin/cassandra -pf
2. cd to bin , call nodetool as ./nodetool -h localhost ring
3. console returned : failed to connect to 'localhost:7199' : connection
refused
BUT ,
at the same centos , all was ok before (1.1.2) .
PS:
cassandra-cli/cqlsh works well (1.1.3)
--
update:
even if add the following in cassandra-env.sh , connection refused as well :
JVM_OPTS=$JVM_OPTS -Djava.rmi.server.hostname=10.10.30.11
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4453) Better support of collections in the binary protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13429190#comment-13429190 ] Jonathan Ellis commented on CASSANDRA-4453: --- Can you summarize the encoding design? In particular where is the type information included? Better support of collections in the binary protocol Key: CASSANDRA-4453 URL: https://issues.apache.org/jira/browse/CASSANDRA-4453 Project: Cassandra Issue Type: Improvement Affects Versions: 1.2 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2 Attachments: 0001-Adds-generics-to-collection-types.txt, 0002-Support-collections-natively-in-the-binary-protocol.txt Currently, collections results are serialized to json string and send that way. This doesn't feel right at all for the binary protocol and we should use a simple binary serialization of the collection instead. For the thrift protocol, we might want to keep the json serialization or use the same binary serialization. I don't really have much opinion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4453) Better support of collections in the binary protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4453: Attachment: (was: 0002-Support-collections-natively-in-the-binary-protocol.txt) Better support of collections in the binary protocol Key: CASSANDRA-4453 URL: https://issues.apache.org/jira/browse/CASSANDRA-4453 Project: Cassandra Issue Type: Improvement Affects Versions: 1.2 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2 Attachments: 0001-Adds-generics-to-collection-types.txt, 0002-Support-collections-natively-in-the-binary-protocol.txt, 0003-Use-binary-format-for-thrift.txt Currently, collections results are serialized to json string and send that way. This doesn't feel right at all for the binary protocol and we should use a simple binary serialization of the collection instead. For the thrift protocol, we might want to keep the json serialization or use the same binary serialization. I don't really have much opinion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4453) Better support of collections in the binary protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4453: Attachment: 0003-Use-binary-format-for-thrift.txt 0002-Support-collections-natively-in-the-binary-protocol.txt 0001-Adds-generics-to-collection-types.txt Better support of collections in the binary protocol Key: CASSANDRA-4453 URL: https://issues.apache.org/jira/browse/CASSANDRA-4453 Project: Cassandra Issue Type: Improvement Affects Versions: 1.2 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2 Attachments: 0001-Adds-generics-to-collection-types.txt, 0002-Support-collections-natively-in-the-binary-protocol.txt, 0003-Use-binary-format-for-thrift.txt Currently, collections results are serialized to json string and send that way. This doesn't feel right at all for the binary protocol and we should use a simple binary serialization of the collection instead. For the thrift protocol, we might want to keep the json serialization or use the same binary serialization. I don't really have much opinion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4453) Better support of collections in the binary protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13429194#comment-13429194 ] Sylvain Lebresne commented on CASSANDRA-4453: - The encoding is the more straightforward I can think of: each collection stars by an int representing the number of elements, following by each element as a short size followed by the bytes. For the type information, they are all in the metadata. I've rebased the patch, and I'm attaching a 3rd patch that switch the thrift transport to the binary format too. JSON was fun for the initial testing but the more I think about it, the less I think we should keep it. There was also a bug on the thrift side, in that we were using only the (short) name of the AbstractType class in the CQLRow metadata. However, for collection we want to know the type of the elements too, so we want to return the full name of the class. The third patch fixes that. Better support of collections in the binary protocol Key: CASSANDRA-4453 URL: https://issues.apache.org/jira/browse/CASSANDRA-4453 Project: Cassandra Issue Type: Improvement Affects Versions: 1.2 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2 Attachments: 0001-Adds-generics-to-collection-types.txt, 0002-Support-collections-natively-in-the-binary-protocol.txt, 0003-Use-binary-format-for-thrift.txt Currently, collections results are serialized to json string and send that way. This doesn't feel right at all for the binary protocol and we should use a simple binary serialization of the collection instead. For the thrift protocol, we might want to keep the json serialization or use the same binary serialization. I don't really have much opinion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4453) Better support of collections in the binary protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13429212#comment-13429212 ] Jonathan Ellis commented on CASSANDRA-4453: --- does name.type.toString return the full org.apache.cassandra package name too? Better support of collections in the binary protocol Key: CASSANDRA-4453 URL: https://issues.apache.org/jira/browse/CASSANDRA-4453 Project: Cassandra Issue Type: Improvement Affects Versions: 1.2 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2 Attachments: 0001-Adds-generics-to-collection-types.txt, 0002-Support-collections-natively-in-the-binary-protocol.txt, 0003-Use-binary-format-for-thrift.txt Currently, collections results are serialized to json string and send that way. This doesn't feel right at all for the binary protocol and we should use a simple binary serialization of the collection instead. For the thrift protocol, we might want to keep the json serialization or use the same binary serialization. I don't really have much opinion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4453) Better support of collections in the binary protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13429215#comment-13429215 ] Sylvain Lebresne commented on CASSANDRA-4453: - bq. does name.type.toString return the full org.apache.cassandra package name too? It does currently yes. In the javadoc of AbstractType.toString(), I wrote Note that for backwards compatibility this includes the full classname. For CQL purposes the short name is fine, but damn if I remember to which extent using the short name would break compatibility. That is, as long as TypeParser.parse() is able to understand both the long and the short name, I think we should be fine in using the short name. Better support of collections in the binary protocol Key: CASSANDRA-4453 URL: https://issues.apache.org/jira/browse/CASSANDRA-4453 Project: Cassandra Issue Type: Improvement Affects Versions: 1.2 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2 Attachments: 0001-Adds-generics-to-collection-types.txt, 0002-Support-collections-natively-in-the-binary-protocol.txt, 0003-Use-binary-format-for-thrift.txt Currently, collections results are serialized to json string and send that way. This doesn't feel right at all for the binary protocol and we should use a simple binary serialization of the collection instead. For the thrift protocol, we might want to keep the json serialization or use the same binary serialization. I don't really have much opinion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4411) Assertion with LCS compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-4411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13429257#comment-13429257
]
Omid Aladini commented on CASSANDRA-4411:
-
@Mina were the sstables created after CASSANDRA-4321 patch? Otherwise
offline-scrub with --manifest-check is unlikely to solve the problem (or at
least I don't understand how) since there would still be out-of-order sstables
existing.
Assertion with LCS compaction
-
Key: CASSANDRA-4411
URL: https://issues.apache.org/jira/browse/CASSANDRA-4411
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.2
Reporter: Anton Winter
Assignee: Sylvain Lebresne
Fix For: 1.1.3
Attachments: 0001-Add-debugging-info-for-LCS.txt, 4411-followup.txt,
4411.txt, assertion-w-more-debugging-info-omid.log,
assertion.moreinfo.system.log, system.log
As instructed in CASSANDRA-4321 I have raised this issue as a continuation of
that issue as it appears the problem still exists.
I have repeatedly run sstablescrub across all my nodes after the 1.1.2
upgrade until sstablescrub shows no errors. The exceptions described in
CASSANDRA-4321 do not occur as frequently now but the integrity check still
throws exceptions on a number of nodes. Once those exceptions occur
compactionstats shows a large number of pending tasks with no progression
afterwards.
{code}
ERROR [CompactionExecutor:150] 2012-07-05 04:26:15,570
AbstractCassandraDaemon.java (line 134) Exception in thread
Thread[CompactionExecutor:150,1,main]
java.lang.AssertionError
at
org.apache.cassandra.db.compaction.LeveledManifest.promote(LeveledManifest.java:214)
at
org.apache.cassandra.db.compaction.LeveledCompactionStrategy.handleNotification(LeveledCompactionStrategy.java:158)
at
org.apache.cassandra.db.DataTracker.notifySSTablesChanged(DataTracker.java:531)
at
org.apache.cassandra.db.DataTracker.replaceCompactedSSTables(DataTracker.java:254)
at
org.apache.cassandra.db.ColumnFamilyStore.replaceCompactedSSTables(ColumnFamilyStore.java:978)
at
org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:200)
at
org.apache.cassandra.db.compaction.LeveledCompactionTask.execute(LeveledCompactionTask.java:50)
at
org.apache.cassandra.db.compaction.CompactionManager$1.runMayThrow(CompactionManager.java:150)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
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:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2118) Provide failure modes if issues with the underlying filesystem of a node
[ https://issues.apache.org/jira/browse/CASSANDRA-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-2118: - Attachment: CASSANDRA-2118-part1.patch Provide failure modes if issues with the underlying filesystem of a node Key: CASSANDRA-2118 URL: https://issues.apache.org/jira/browse/CASSANDRA-2118 Project: Cassandra Issue Type: Sub-task Components: Core Reporter: Chris Goffinet Assignee: Aleksey Yeschenko Fix For: 1.2 Attachments: 0001-Provide-failure-modes-if-issues-with-the-underlying-.patch, 0001-Provide-failure-modes-if-issues-with-the-underlying-v2.patch, 0001-Provide-failure-modes-if-issues-with-the-underlying-v3.patch, CASSANDRA-2118-part1.patch CASSANDRA-2116 introduces the ability to detect FS errors. Let's provide a mode in cassandra.yaml so operators can decide that in the event of failure what to do: 1) standard - means continue on all errors (default) 2) read - means only stop gossip/rpc server if 'reads' fail from drive, writes can fail but not kill gossip/rpc server 3) readwrite - means stop gossip/rpc server if any read or write errors. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4453) Better support of collections in the binary protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13429292#comment-13429292 ] Jonathan Ellis commented on CASSANDRA-4453: --- Maybe we should introduce a separate method then to generate shortname + parameters. Full package will bloat things a *lot* for small resultsets. Better support of collections in the binary protocol Key: CASSANDRA-4453 URL: https://issues.apache.org/jira/browse/CASSANDRA-4453 Project: Cassandra Issue Type: Improvement Affects Versions: 1.2 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2 Attachments: 0001-Adds-generics-to-collection-types.txt, 0002-Support-collections-natively-in-the-binary-protocol.txt, 0003-Use-binary-format-for-thrift.txt Currently, collections results are serialized to json string and send that way. This doesn't feel right at all for the binary protocol and we should use a simple binary serialization of the collection instead. For the thrift protocol, we might want to keep the json serialization or use the same binary serialization. I don't really have much opinion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Update of API by BenjaminBlack
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The API page has been changed by BenjaminBlack: http://wiki.apache.org/cassandra/API?action=diffrev1=30rev2=31 Comment: Clarify semantics of reversed for SliceRange ||'''Attribute''' ||'''Type''' ||'''Default''' ||'''Required''' ||'''Description''' || ||`start` ||`binary` ||n/a ||Y ||The column name to start the slice with. This attribute is not required, though there is no default value, and can be safely set to `''`, i.e., an empty byte array, to start with the first column name. Otherwise, it must be a valid value under the rules of the Comparator defined for the given `ColumnFamily`. || ||`finish` ||`binary` ||n/a ||Y ||The column name to stop the slice at. This attribute is not required, though there is no default value, and can be safely set to an empty byte array to not stop until `count` results are seen. Otherwise, it must also be a valid value to the `ColumnFamily` Comparator. || - ||`reversed` ||`bool` ||`false` ||Y ||Whether the results should be ordered in reversed order. Similar to `ORDER BY blah DESC` in SQL. || + ||`reversed` ||`bool` ||`false` ||Y ||Whether the results should be ordered in reversed order. Similar to `ORDER BY blah DESC` in SQL. When reversed is `true`, `start` will determine the right end of the range while `finish` will determine the left, meaning `start` must be = `finish`.|| ||`count` ||`integer` ||`100` ||Y ||How many columns to return. Similar to `LIMIT 100` in SQL. May be arbitrarily large, but Thrift will materialize the whole result into memory before returning it to the client, so be aware that you may be better served by iterating through slices by passing the last value of one call in as the `start` of the next instead of increasing `count` arbitrarily large. ||
[jira] [Commented] (CASSANDRA-4453) Better support of collections in the binary protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13429299#comment-13429299 ] Sylvain Lebresne commented on CASSANDRA-4453: - bq. Full package will bloat things a lot for small resultsets. I note however that this would be only for the thrift transport. The binary protocol has short (2 byte) code for all the native types and this patch extend it to collections. For this reason I'm a bit reluctant to introduce a whole new method. Though as I said above, we can probably just use the short name in the existing toString() provided we make sure TypeParser.pase() is fine parsing both full and short class names (a quick check says it works just fine). I think I initially kept long names in toString() only for compatibility with old nodes that weren't using TypeParser when decoding types in schema messages. However, TypeParser is used since at least 1.0 and besides, we've broken schema messages compatibility since then so this likely does not matter anymore. To sum that up, I think we're fine if we just s/getClass().getName()/getClass().getSimpleName()/ in AbstractType.toString(). Better support of collections in the binary protocol Key: CASSANDRA-4453 URL: https://issues.apache.org/jira/browse/CASSANDRA-4453 Project: Cassandra Issue Type: Improvement Affects Versions: 1.2 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2 Attachments: 0001-Adds-generics-to-collection-types.txt, 0002-Support-collections-natively-in-the-binary-protocol.txt, 0003-Use-binary-format-for-thrift.txt Currently, collections results are serialized to json string and send that way. This doesn't feel right at all for the binary protocol and we should use a simple binary serialization of the collection instead. For the thrift protocol, we might want to keep the json serialization or use the same binary serialization. I don't really have much opinion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3680) Add Support for Composite Secondary Indexes
[
https://issues.apache.org/jira/browse/CASSANDRA-3680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13429377#comment-13429377
]
Yuki Morishita commented on CASSANDRA-3680:
---
hmm, filtering with key and 2I works, but this time I get wrong value for key.
{code}
cqlsh:3680 select * from blogs;
blog_id | posted_at| author | content
-+--++-
1 | 2012-11-11 00:00:00-0600 |foo | bar
2 | 2012-11-12 00:00:00-0600 |foo | baz
3 | 2012-11-11 00:00:00-0600 |qux |quux
cqlsh:3680 select * from blogs where author='foo' and posted_at = '2012-11-11';
blog_id | posted_at| author | content
-+--++-
2 | 2012-11-11 00:00:00-0600 |foo | bar
{code}
blog_id should be '1'.
{code}
cqlsh:3680 select * from blogs where author='foo';
blog_id | posted_at| author | content
-+--++-
2 | 2012-11-11 00:00:00-0600 |foo | bar
2 | 2012-11-12 00:00:00-0600 |foo | baz
{code}
Here, something is wrong with first row in result set.
Add Support for Composite Secondary Indexes
---
Key: CASSANDRA-3680
URL: https://issues.apache.org/jira/browse/CASSANDRA-3680
Project: Cassandra
Issue Type: Sub-task
Reporter: T Jake Luciani
Assignee: Sylvain Lebresne
Labels: cql3, secondary_index
Fix For: 1.2
Attachments: 0001-Secondary-indexes-on-composite-columns.txt
CASSANDRA-2474 and CASSANDRA-3647 add the ability to transpose wide rows
differently, for efficiency and functionality secondary index api needs to be
altered to allow composite indexes.
I think this will require the IndexManager api to have a
maybeIndex(ByteBuffer column) method that SS can call and implement a
PerRowSecondaryIndex per column, break the composite into parts and index
specific bits, also including the base rowkey.
Then a search against a TRANSPOSED row or DOCUMENT will be possible.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4496) NPE on creating secondary index from Hector
David Semeria created CASSANDRA-4496:
Summary: NPE on creating secondary index from Hector
Key: CASSANDRA-4496
URL: https://issues.apache.org/jira/browse/CASSANDRA-4496
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.3, 1.1.2
Environment: Ubuntu 12.4
Linux 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6 14:25:57 UTC 2012 x86_64 x86_64
x86_64 GNU/Linux
java version 1.7.0
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode)
Reporter: David Semeria
The following code has been working fine up to and including 1.0.x
public static String createIndexedColumnFamily(String cf){
Cluster cluster = HectorConfig.cluster;
ComparatorType ctName =
ComparatorType.getByClassName(JNameComparator.class.getName());
try{
cluster.dropColumnFamily(HectorConfig.dfltKeyspaceName, cf );
} catch (Exception e){}
ListColumnDefinition cdL = new ArrayListColumnDefinition();
BasicColumnDefinition cd;
cd = new BasicColumnDefinition();
cd.setName(ss.toByteBuffer(id));
cd.setIndexName(id);
cd.setIndexType(ColumnIndexType.KEYS);
cd.setValidationClass(JValueComparator.class.getName());
cdL.add(cd);
}
}
With 1.1.3, cassandra throws the following error:
david@vlap1:~/opt/cassandra$ sudo bin/cassandra -f
xss = -ea -javaagent:/usr/share/cassandra/lib/jamm-0.2.5.jar
-XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -Xms128M -Xmx128M -Xmn32M
-XX:+HeapDumpOnOutOfMemoryError -Xss160k
INFO 23:15:31,333 Logging initialized
INFO 23:15:31,337 JVM vendor/version: Java HotSpot(TM) 64-Bit Server VM/1.7.0
INFO 23:15:31,338 Heap size: 130875392/130875392
INFO 23:15:31,338 Classpath:
/etc/cassandra:/usr/share/cassandra/lib/antlr-3.2.jar:/usr/share/cassandra/lib/avro-1.4.0-fixes.jar:/usr/share/cassandra/lib/avro-1.4.0-sources-fixes.jar:/usr/share/cassandra/lib/commons-cli-1.1.jar:/usr/share/cassandra/lib/commons-codec-1.2.jar:/usr/share/cassandra/lib/commons-lang-2.4.jar:/usr/share/cassandra/lib/compress-lzf-0.8.4.jar:/usr/share/cassandra/lib/concurrentlinkedhashmap-lru-1.3.jar:/usr/share/cassandra/lib/guava-r08.jar:/usr/share/cassandra/lib/hector-core-1.0-3.jar:/usr/share/cassandra/lib/high-scale-lib-1.1.2.jar:/usr/share/cassandra/lib/jackson-core-asl-1.9.2.jar:/usr/share/cassandra/lib/jackson-mapper-asl-1.9.2.jar:/usr/share/cassandra/lib/jamm-0.2.5.jar:/usr/share/cassandra/lib/jellyfish.jar:/usr/share/cassandra/lib/jline-0.9.94.jar:/usr/share/cassandra/lib/json-simple-1.1.jar:/usr/share/cassandra/lib/libthrift-0.7.0.jar:/usr/share/cassandra/lib/log4j-1.2.16.jar:/usr/share/cassandra/lib/metrics-core-2.0.3.jar:/usr/share/cassandra/lib/servlet-api-2.5-20081211.jar:/usr/share/cassandra/lib/slf4j-api-1.6.1.jar:/usr/share/cassandra/lib/slf4j-log4j12-1.6.1.jar:/usr/share/cassandra/lib/snakeyaml-1.6.jar:/usr/share/cassandra/lib/snappy-java-1.0.4.1.jar:/usr/share/cassandra/lib/snaptree-0.1.jar:/usr/share/cassandra/apache-cassandra-1.1.2.jar:/usr/share/cassandra/apache-cassandra-thrift-1.1.2.jar:/usr/share/cassandra/apache-cassandra.jar:/usr/share/cassandra/stress.jar:/usr/share/cassandra/lib/jamm-0.2.5.jar
INFO 23:15:31,340 JNA not found. Native methods will be disabled.
INFO 23:15:31,351 Loading settings from file:/etc/cassandra/cassandra.yaml
INFO 23:15:31,566 DiskAccessMode 'auto' determined to be mmap, indexAccessMode
is mmap
INFO 23:15:31,875 Global memtable threshold is enabled at 41MB
INFO 23:15:32,380 Initializing key cache with capacity of 6 MBs.
INFO 23:15:32,394 Scheduling key cache save to each 14400 seconds (going to
save all keys).
INFO 23:15:32,395 Initializing row cache with capacity of 0 MBs and provider
org.apache.cassandra.cache.SerializingCacheProvider
INFO 23:15:32,400 Scheduling row cache save to each 0 seconds (going to save
all keys).
INFO 23:15:32,661 Couldn't detect any schema definitions in local storage.
INFO 23:15:32,665 Found table data in data directories. Consider using the CLI
to define your schema.
INFO 23:15:32,714 No commitlog files found; skipping replay
INFO 23:15:32,740 Cassandra version: 1.1.2
INFO 23:15:32,754 Thrift API version: 19.32.0
INFO 23:15:32,763 CQL supported versions: 2.0.0,3.0.0-beta1 (default: 2.0.0)
INFO 23:15:32,803 Loading persisted ring state
INFO 23:15:32,807 Starting up server gossip
INFO 23:15:32,821 Enqueuing flush of Memtable-LocationInfo@1473831778(163/203
serialized/live bytes, 3 ops)
INFO 23:15:32,822 Writing Memtable-LocationInfo@1473831778(163/203
serialized/live bytes, 3 ops)
INFO 23:15:33,072 Completed flushing
/var/lib/cassandra/data/system/LocationInfo/system-LocationInfo-hd-1-Data.db
(235 bytes) for commitlog position ReplayPosition(segmentId=126105713813993,
position=587)
INFO 23:15:33,094 Starting Messaging Service on port 7000
INFO 23:15:33,102
[jira] [Updated] (CASSANDRA-4496) NPE on creating secondary index from Hector
[
https://issues.apache.org/jira/browse/CASSANDRA-4496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Semeria updated CASSANDRA-4496:
-
Description:
The following code has been working fine up to and including 1.0.x
public static String createIndexedColumnFamily(String cf){
Cluster cluster = HectorConfig.cluster;
ComparatorType ctName =
ComparatorType.getByClassName(JNameComparator.class.getName());
try{
cluster.dropColumnFamily(HectorConfig.dfltKeyspaceName, cf );
} catch (Exception e){}
ListColumnDefinition cdL = new ArrayListColumnDefinition();
BasicColumnDefinition cd;
cd = new BasicColumnDefinition();
cd.setName(ss.toByteBuffer(id));
cd.setIndexName(id);
cd.setIndexType(ColumnIndexType.KEYS);
cd.setValidationClass(JValueComparator.class.getName());
cdL.add(cd);
ThriftCfDef cfd= new ThriftCfDef(HectorConfig.dfltKeyspaceName, cf, ctName,
cdL);
cfd.setKeyValidationClass(ComparatorType.UTF8TYPE.getClassName());
cfd.setDefaultValidationClass(JValueComparator.class.getName());
cluster.addColumnFamily(cfd);
return created: + cf;
}
}
I'm inclined to exclude the presence of the custom comparator since:
(1) there is no issue using it if the cf doesn't have a secondary index
(2) the stack trace (see below) doesn't include the comparator
With 1.1.3, the above code cassandra throws the following error:
david@vlap1:~/opt/cassandra$ sudo bin/cassandra -f
xss = -ea -javaagent:/usr/share/cassandra/lib/jamm-0.2.5.jar
-XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -Xms128M -Xmx128M -Xmn32M
-XX:+HeapDumpOnOutOfMemoryError -Xss160k
INFO 23:15:31,333 Logging initialized
INFO 23:15:31,337 JVM vendor/version: Java HotSpot(TM) 64-Bit Server VM/1.7.0
INFO 23:15:31,338 Heap size: 130875392/130875392
INFO 23:15:31,338 Classpath:
/etc/cassandra:/usr/share/cassandra/lib/antlr-3.2.jar:/usr/share/cassandra/lib/avro-1.4.0-fixes.jar:/usr/share/cassandra/lib/avro-1.4.0-sources-fixes.jar:/usr/share/cassandra/lib/commons-cli-1.1.jar:/usr/share/cassandra/lib/commons-codec-1.2.jar:/usr/share/cassandra/lib/commons-lang-2.4.jar:/usr/share/cassandra/lib/compress-lzf-0.8.4.jar:/usr/share/cassandra/lib/concurrentlinkedhashmap-lru-1.3.jar:/usr/share/cassandra/lib/guava-r08.jar:/usr/share/cassandra/lib/hector-core-1.0-3.jar:/usr/share/cassandra/lib/high-scale-lib-1.1.2.jar:/usr/share/cassandra/lib/jackson-core-asl-1.9.2.jar:/usr/share/cassandra/lib/jackson-mapper-asl-1.9.2.jar:/usr/share/cassandra/lib/jamm-0.2.5.jar:/usr/share/cassandra/lib/jellyfish.jar:/usr/share/cassandra/lib/jline-0.9.94.jar:/usr/share/cassandra/lib/json-simple-1.1.jar:/usr/share/cassandra/lib/libthrift-0.7.0.jar:/usr/share/cassandra/lib/log4j-1.2.16.jar:/usr/share/cassandra/lib/metrics-core-2.0.3.jar:/usr/share/cassandra/lib/servlet-api-2.5-20081211.jar:/usr/share/cassandra/lib/slf4j-api-1.6.1.jar:/usr/share/cassandra/lib/slf4j-log4j12-1.6.1.jar:/usr/share/cassandra/lib/snakeyaml-1.6.jar:/usr/share/cassandra/lib/snappy-java-1.0.4.1.jar:/usr/share/cassandra/lib/snaptree-0.1.jar:/usr/share/cassandra/apache-cassandra-1.1.2.jar:/usr/share/cassandra/apache-cassandra-thrift-1.1.2.jar:/usr/share/cassandra/apache-cassandra.jar:/usr/share/cassandra/stress.jar:/usr/share/cassandra/lib/jamm-0.2.5.jar
INFO 23:15:31,340 JNA not found. Native methods will be disabled.
INFO 23:15:31,351 Loading settings from file:/etc/cassandra/cassandra.yaml
INFO 23:15:31,566 DiskAccessMode 'auto' determined to be mmap, indexAccessMode
is mmap
INFO 23:15:31,875 Global memtable threshold is enabled at 41MB
INFO 23:15:32,380 Initializing key cache with capacity of 6 MBs.
INFO 23:15:32,394 Scheduling key cache save to each 14400 seconds (going to
save all keys).
INFO 23:15:32,395 Initializing row cache with capacity of 0 MBs and provider
org.apache.cassandra.cache.SerializingCacheProvider
INFO 23:15:32,400 Scheduling row cache save to each 0 seconds (going to save
all keys).
INFO 23:15:32,661 Couldn't detect any schema definitions in local storage.
INFO 23:15:32,665 Found table data in data directories. Consider using the CLI
to define your schema.
INFO 23:15:32,714 No commitlog files found; skipping replay
INFO 23:15:32,740 Cassandra version: 1.1.2
INFO 23:15:32,754 Thrift API version: 19.32.0
INFO 23:15:32,763 CQL supported versions: 2.0.0,3.0.0-beta1 (default: 2.0.0)
INFO 23:15:32,803 Loading persisted ring state
INFO 23:15:32,807 Starting up server gossip
INFO 23:15:32,821 Enqueuing flush of Memtable-LocationInfo@1473831778(163/203
serialized/live bytes, 3 ops)
INFO 23:15:32,822 Writing Memtable-LocationInfo@1473831778(163/203
serialized/live bytes, 3 ops)
INFO 23:15:33,072 Completed flushing
/var/lib/cassandra/data/system/LocationInfo/system-LocationInfo-hd-1-Data.db
(235 bytes) for commitlog position ReplayPosition(segmentId=126105713813993,
position=587)
INFO
[jira] [Updated] (CASSANDRA-4496) NPE on creating secondary index from Hector
[
https://issues.apache.org/jira/browse/CASSANDRA-4496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Semeria updated CASSANDRA-4496:
-
Description:
The following code has been working fine up to and including 1.0.x
public static String createIndexedColumnFamily(String cf){
Cluster cluster = HectorConfig.cluster;
ComparatorType ctName =
ComparatorType.getByClassName(JNameComparator.class.getName());
try{
cluster.dropColumnFamily(HectorConfig.dfltKeyspaceName, cf );
} catch (Exception e){}
ListColumnDefinition cdL = new ArrayListColumnDefinition();
BasicColumnDefinition cd;
cd = new BasicColumnDefinition();
cd.setName(ss.toByteBuffer(id));
cd.setIndexName(id);
cd.setIndexType(ColumnIndexType.KEYS);
cd.setValidationClass(JValueComparator.class.getName());
cdL.add(cd);
ThriftCfDef cfd= new ThriftCfDef(HectorConfig.dfltKeyspaceName, cf, ctName,
cdL);
cfd.setKeyValidationClass(ComparatorType.UTF8TYPE.getClassName());
cfd.setDefaultValidationClass(JValueComparator.class.getName());
cluster.addColumnFamily(cfd);
return created: + cf;
}
}
I'm inclined to exclude the presence of the custom comparator since:
(1) there is no issue using it if the cf doesn't have a secondary index
(2) the stack trace (see below) doesn't include the comparator
The above code throws the following error in Cassandra 1.1.3
david@vlap1:~/opt/cassandra$ sudo bin/cassandra -f
xss = -ea -javaagent:/usr/share/cassandra/lib/jamm-0.2.5.jar
-XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -Xms128M -Xmx128M -Xmn32M
-XX:+HeapDumpOnOutOfMemoryError -Xss160k
INFO 23:15:31,333 Logging initialized
INFO 23:15:31,337 JVM vendor/version: Java HotSpot(TM) 64-Bit Server VM/1.7.0
INFO 23:15:31,338 Heap size: 130875392/130875392
INFO 23:15:31,338 Classpath:
/etc/cassandra:/usr/share/cassandra/lib/antlr-3.2.jar:/usr/share/cassandra/lib/avro-1.4.0-fixes.jar:/usr/share/cassandra/lib/avro-1.4.0-sources-fixes.jar:/usr/share/cassandra/lib/commons-cli-1.1.jar:/usr/share/cassandra/lib/commons-codec-1.2.jar:/usr/share/cassandra/lib/commons-lang-2.4.jar:/usr/share/cassandra/lib/compress-lzf-0.8.4.jar:/usr/share/cassandra/lib/concurrentlinkedhashmap-lru-1.3.jar:/usr/share/cassandra/lib/guava-r08.jar:/usr/share/cassandra/lib/hector-core-1.0-3.jar:/usr/share/cassandra/lib/high-scale-lib-1.1.2.jar:/usr/share/cassandra/lib/jackson-core-asl-1.9.2.jar:/usr/share/cassandra/lib/jackson-mapper-asl-1.9.2.jar:/usr/share/cassandra/lib/jamm-0.2.5.jar:/usr/share/cassandra/lib/jellyfish.jar:/usr/share/cassandra/lib/jline-0.9.94.jar:/usr/share/cassandra/lib/json-simple-1.1.jar:/usr/share/cassandra/lib/libthrift-0.7.0.jar:/usr/share/cassandra/lib/log4j-1.2.16.jar:/usr/share/cassandra/lib/metrics-core-2.0.3.jar:/usr/share/cassandra/lib/servlet-api-2.5-20081211.jar:/usr/share/cassandra/lib/slf4j-api-1.6.1.jar:/usr/share/cassandra/lib/slf4j-log4j12-1.6.1.jar:/usr/share/cassandra/lib/snakeyaml-1.6.jar:/usr/share/cassandra/lib/snappy-java-1.0.4.1.jar:/usr/share/cassandra/lib/snaptree-0.1.jar:/usr/share/cassandra/apache-cassandra-1.1.2.jar:/usr/share/cassandra/apache-cassandra-thrift-1.1.2.jar:/usr/share/cassandra/apache-cassandra.jar:/usr/share/cassandra/stress.jar:/usr/share/cassandra/lib/jamm-0.2.5.jar
INFO 23:15:31,340 JNA not found. Native methods will be disabled.
INFO 23:15:31,351 Loading settings from file:/etc/cassandra/cassandra.yaml
INFO 23:15:31,566 DiskAccessMode 'auto' determined to be mmap, indexAccessMode
is mmap
INFO 23:15:31,875 Global memtable threshold is enabled at 41MB
INFO 23:15:32,380 Initializing key cache with capacity of 6 MBs.
INFO 23:15:32,394 Scheduling key cache save to each 14400 seconds (going to
save all keys).
INFO 23:15:32,395 Initializing row cache with capacity of 0 MBs and provider
org.apache.cassandra.cache.SerializingCacheProvider
INFO 23:15:32,400 Scheduling row cache save to each 0 seconds (going to save
all keys).
INFO 23:15:32,661 Couldn't detect any schema definitions in local storage.
INFO 23:15:32,665 Found table data in data directories. Consider using the CLI
to define your schema.
INFO 23:15:32,714 No commitlog files found; skipping replay
INFO 23:15:32,740 Cassandra version: 1.1.2
INFO 23:15:32,754 Thrift API version: 19.32.0
INFO 23:15:32,763 CQL supported versions: 2.0.0,3.0.0-beta1 (default: 2.0.0)
INFO 23:15:32,803 Loading persisted ring state
INFO 23:15:32,807 Starting up server gossip
INFO 23:15:32,821 Enqueuing flush of Memtable-LocationInfo@1473831778(163/203
serialized/live bytes, 3 ops)
INFO 23:15:32,822 Writing Memtable-LocationInfo@1473831778(163/203
serialized/live bytes, 3 ops)
INFO 23:15:33,072 Completed flushing
/var/lib/cassandra/data/system/LocationInfo/system-LocationInfo-hd-1-Data.db
(235 bytes) for commitlog position ReplayPosition(segmentId=126105713813993,
position=587)
INFO 23:15:33,094
[jira] [Updated] (CASSANDRA-4496) NPE on creating secondary index from Hector
[
https://issues.apache.org/jira/browse/CASSANDRA-4496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Semeria updated CASSANDRA-4496:
-
Description:
The following code has been working fine up to and including 1.0.x
public static String createIndexedColumnFamily(String cf){
Cluster cluster = HectorConfig.cluster;
ComparatorType ctName =
ComparatorType.getByClassName(JNameComparator.class.getName());
try{
cluster.dropColumnFamily(HectorConfig.dfltKeyspaceName, cf );
} catch (Exception e){}
ListColumnDefinition cdL = new ArrayListColumnDefinition();
BasicColumnDefinition cd;
cd = new BasicColumnDefinition();
cd.setName(ss.toByteBuffer(id));
cd.setIndexName(id);
cd.setIndexType(ColumnIndexType.KEYS);
cd.setValidationClass(JValueComparator.class.getName());
cdL.add(cd);
ThriftCfDef cfd= new ThriftCfDef(HectorConfig.dfltKeyspaceName, cf, ctName,
cdL);
cfd.setKeyValidationClass(ComparatorType.UTF8TYPE.getClassName());
cfd.setDefaultValidationClass(JValueComparator.class.getName());
cluster.addColumnFamily(cfd);
return created: + cf;
}
}
I'm inclined to exclude the presence of the custom comparator since:
(1) there is no issue using it if the cf doesn't have a secondary index
(2) the stack trace (see below) doesn't include the comparator
The above code throws the following error in Cassandra 1.1.2
david@vlap1:~/opt/cassandra$ sudo bin/cassandra -f
xss = -ea -javaagent:/usr/share/cassandra/lib/jamm-0.2.5.jar
-XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -Xms128M -Xmx128M -Xmn32M
-XX:+HeapDumpOnOutOfMemoryError -Xss160k
INFO 23:15:31,333 Logging initialized
INFO 23:15:31,337 JVM vendor/version: Java HotSpot(TM) 64-Bit Server VM/1.7.0
INFO 23:15:31,338 Heap size: 130875392/130875392
INFO 23:15:31,338 Classpath:
/etc/cassandra:/usr/share/cassandra/lib/antlr-3.2.jar:/usr/share/cassandra/lib/avro-1.4.0-fixes.jar:/usr/share/cassandra/lib/avro-1.4.0-sources-fixes.jar:/usr/share/cassandra/lib/commons-cli-1.1.jar:/usr/share/cassandra/lib/commons-codec-1.2.jar:/usr/share/cassandra/lib/commons-lang-2.4.jar:/usr/share/cassandra/lib/compress-lzf-0.8.4.jar:/usr/share/cassandra/lib/concurrentlinkedhashmap-lru-1.3.jar:/usr/share/cassandra/lib/guava-r08.jar:/usr/share/cassandra/lib/hector-core-1.0-3.jar:/usr/share/cassandra/lib/high-scale-lib-1.1.2.jar:/usr/share/cassandra/lib/jackson-core-asl-1.9.2.jar:/usr/share/cassandra/lib/jackson-mapper-asl-1.9.2.jar:/usr/share/cassandra/lib/jamm-0.2.5.jar:/usr/share/cassandra/lib/jellyfish.jar:/usr/share/cassandra/lib/jline-0.9.94.jar:/usr/share/cassandra/lib/json-simple-1.1.jar:/usr/share/cassandra/lib/libthrift-0.7.0.jar:/usr/share/cassandra/lib/log4j-1.2.16.jar:/usr/share/cassandra/lib/metrics-core-2.0.3.jar:/usr/share/cassandra/lib/servlet-api-2.5-20081211.jar:/usr/share/cassandra/lib/slf4j-api-1.6.1.jar:/usr/share/cassandra/lib/slf4j-log4j12-1.6.1.jar:/usr/share/cassandra/lib/snakeyaml-1.6.jar:/usr/share/cassandra/lib/snappy-java-1.0.4.1.jar:/usr/share/cassandra/lib/snaptree-0.1.jar:/usr/share/cassandra/apache-cassandra-1.1.2.jar:/usr/share/cassandra/apache-cassandra-thrift-1.1.2.jar:/usr/share/cassandra/apache-cassandra.jar:/usr/share/cassandra/stress.jar:/usr/share/cassandra/lib/jamm-0.2.5.jar
INFO 23:15:31,340 JNA not found. Native methods will be disabled.
INFO 23:15:31,351 Loading settings from file:/etc/cassandra/cassandra.yaml
INFO 23:15:31,566 DiskAccessMode 'auto' determined to be mmap, indexAccessMode
is mmap
INFO 23:15:31,875 Global memtable threshold is enabled at 41MB
INFO 23:15:32,380 Initializing key cache with capacity of 6 MBs.
INFO 23:15:32,394 Scheduling key cache save to each 14400 seconds (going to
save all keys).
INFO 23:15:32,395 Initializing row cache with capacity of 0 MBs and provider
org.apache.cassandra.cache.SerializingCacheProvider
INFO 23:15:32,400 Scheduling row cache save to each 0 seconds (going to save
all keys).
INFO 23:15:32,661 Couldn't detect any schema definitions in local storage.
INFO 23:15:32,665 Found table data in data directories. Consider using the CLI
to define your schema.
INFO 23:15:32,714 No commitlog files found; skipping replay
INFO 23:15:32,740 Cassandra version: 1.1.2
INFO 23:15:32,754 Thrift API version: 19.32.0
INFO 23:15:32,763 CQL supported versions: 2.0.0,3.0.0-beta1 (default: 2.0.0)
INFO 23:15:32,803 Loading persisted ring state
INFO 23:15:32,807 Starting up server gossip
INFO 23:15:32,821 Enqueuing flush of Memtable-LocationInfo@1473831778(163/203
serialized/live bytes, 3 ops)
INFO 23:15:32,822 Writing Memtable-LocationInfo@1473831778(163/203
serialized/live bytes, 3 ops)
INFO 23:15:33,072 Completed flushing
/var/lib/cassandra/data/system/LocationInfo/system-LocationInfo-hd-1-Data.db
(235 bytes) for commitlog position ReplayPosition(segmentId=126105713813993,
position=587)
INFO
[jira] [Updated] (CASSANDRA-2118) Provide failure modes if issues with the underlying filesystem of a node
[ https://issues.apache.org/jira/browse/CASSANDRA-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-2118: - Attachment: CASSANDRA-2118-v1.patch Provide failure modes if issues with the underlying filesystem of a node Key: CASSANDRA-2118 URL: https://issues.apache.org/jira/browse/CASSANDRA-2118 Project: Cassandra Issue Type: Sub-task Components: Core Reporter: Chris Goffinet Assignee: Aleksey Yeschenko Fix For: 1.2 Attachments: 0001-Provide-failure-modes-if-issues-with-the-underlying-.patch, 0001-Provide-failure-modes-if-issues-with-the-underlying-v2.patch, 0001-Provide-failure-modes-if-issues-with-the-underlying-v3.patch, CASSANDRA-2118-part1.patch, CASSANDRA-2118-v1.patch CASSANDRA-2116 introduces the ability to detect FS errors. Let's provide a mode in cassandra.yaml so operators can decide that in the event of failure what to do: 1) standard - means continue on all errors (default) 2) read - means only stop gossip/rpc server if 'reads' fail from drive, writes can fail but not kill gossip/rpc server 3) readwrite - means stop gossip/rpc server if any read or write errors. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4496) NPE on creating secondary index
[
https://issues.apache.org/jira/browse/CASSANDRA-4496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Semeria updated CASSANDRA-4496:
-
Summary: NPE on creating secondary index (was: NPE on creating secondary
index from Hector)
NPE on creating secondary index
---
Key: CASSANDRA-4496
URL: https://issues.apache.org/jira/browse/CASSANDRA-4496
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.2, 1.1.3
Environment: Ubuntu 12.4
Linux 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6 14:25:57 UTC 2012 x86_64
x86_64 x86_64 GNU/Linux
java version 1.7.0
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode)
Reporter: David Semeria
The following code has been working fine up to and including 1.0.x
public static String createIndexedColumnFamily(String cf){
Cluster cluster = HectorConfig.cluster;
ComparatorType ctName =
ComparatorType.getByClassName(JNameComparator.class.getName());
try{
cluster.dropColumnFamily(HectorConfig.dfltKeyspaceName, cf );
} catch (Exception e){}
ListColumnDefinition cdL = new ArrayListColumnDefinition();
BasicColumnDefinition cd;
cd = new BasicColumnDefinition();
cd.setName(ss.toByteBuffer(id));
cd.setIndexName(id);
cd.setIndexType(ColumnIndexType.KEYS);
cd.setValidationClass(JValueComparator.class.getName());
cdL.add(cd);
ThriftCfDef cfd= new ThriftCfDef(HectorConfig.dfltKeyspaceName, cf,
ctName, cdL);
cfd.setKeyValidationClass(ComparatorType.UTF8TYPE.getClassName());
cfd.setDefaultValidationClass(JValueComparator.class.getName());
cluster.addColumnFamily(cfd);
return created: + cf;
}
}
I'm inclined to exclude the presence of the custom comparator since:
(1) there is no issue using it if the cf doesn't have a secondary index
(2) the stack trace (see below) doesn't include the comparator
The above code throws the following error in Cassandra 1.1.2 and 1.1.3
david@vlap1:~/opt/cassandra$ sudo bin/cassandra -f
xss = -ea -javaagent:/usr/share/cassandra/lib/jamm-0.2.5.jar
-XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -Xms128M -Xmx128M
-Xmn32M -XX:+HeapDumpOnOutOfMemoryError -Xss160k
INFO 23:15:31,333 Logging initialized
INFO 23:15:31,337 JVM vendor/version: Java HotSpot(TM) 64-Bit Server VM/1.7.0
INFO 23:15:31,338 Heap size: 130875392/130875392
INFO 23:15:31,338 Classpath:
/etc/cassandra:/usr/share/cassandra/lib/antlr-3.2.jar:/usr/share/cassandra/lib/avro-1.4.0-fixes.jar:/usr/share/cassandra/lib/avro-1.4.0-sources-fixes.jar:/usr/share/cassandra/lib/commons-cli-1.1.jar:/usr/share/cassandra/lib/commons-codec-1.2.jar:/usr/share/cassandra/lib/commons-lang-2.4.jar:/usr/share/cassandra/lib/compress-lzf-0.8.4.jar:/usr/share/cassandra/lib/concurrentlinkedhashmap-lru-1.3.jar:/usr/share/cassandra/lib/guava-r08.jar:/usr/share/cassandra/lib/hector-core-1.0-3.jar:/usr/share/cassandra/lib/high-scale-lib-1.1.2.jar:/usr/share/cassandra/lib/jackson-core-asl-1.9.2.jar:/usr/share/cassandra/lib/jackson-mapper-asl-1.9.2.jar:/usr/share/cassandra/lib/jamm-0.2.5.jar:/usr/share/cassandra/lib/jellyfish.jar:/usr/share/cassandra/lib/jline-0.9.94.jar:/usr/share/cassandra/lib/json-simple-1.1.jar:/usr/share/cassandra/lib/libthrift-0.7.0.jar:/usr/share/cassandra/lib/log4j-1.2.16.jar:/usr/share/cassandra/lib/metrics-core-2.0.3.jar:/usr/share/cassandra/lib/servlet-api-2.5-20081211.jar:/usr/share/cassandra/lib/slf4j-api-1.6.1.jar:/usr/share/cassandra/lib/slf4j-log4j12-1.6.1.jar:/usr/share/cassandra/lib/snakeyaml-1.6.jar:/usr/share/cassandra/lib/snappy-java-1.0.4.1.jar:/usr/share/cassandra/lib/snaptree-0.1.jar:/usr/share/cassandra/apache-cassandra-1.1.2.jar:/usr/share/cassandra/apache-cassandra-thrift-1.1.2.jar:/usr/share/cassandra/apache-cassandra.jar:/usr/share/cassandra/stress.jar:/usr/share/cassandra/lib/jamm-0.2.5.jar
INFO 23:15:31,340 JNA not found. Native methods will be disabled.
INFO 23:15:31,351 Loading settings from file:/etc/cassandra/cassandra.yaml
INFO 23:15:31,566 DiskAccessMode 'auto' determined to be mmap,
indexAccessMode is mmap
INFO 23:15:31,875 Global memtable threshold is enabled at 41MB
INFO 23:15:32,380 Initializing key cache with capacity of 6 MBs.
INFO 23:15:32,394 Scheduling key cache save to each 14400 seconds (going to
save all keys).
INFO 23:15:32,395 Initializing row cache with capacity of 0 MBs and provider
org.apache.cassandra.cache.SerializingCacheProvider
INFO 23:15:32,400 Scheduling row cache save to each 0 seconds (going to save
all keys).
INFO 23:15:32,661 Couldn't detect any schema definitions in local storage.
INFO 23:15:32,665 Found table data in data directories. Consider using the
CLI to define your schema.
INFO
[jira] [Updated] (CASSANDRA-4489) LCS with Composite Columns NPE
[ https://issues.apache.org/jira/browse/CASSANDRA-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4489: -- Reviewer: jbellis Assignee: Pavel Yaskevich LCS with Composite Columns NPE -- Key: CASSANDRA-4489 URL: https://issues.apache.org/jira/browse/CASSANDRA-4489 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.2 Environment: Mac OS X 10.8 java version 1.6.0_33 Java(TM) SE Runtime Environment (build 1.6.0_33-b03-424-11M3720) Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03-424, mixed mode) Reporter: Wing Lian Assignee: Pavel Yaskevich Creating the CF in cqlsh -3 cqlsh CREATE KEYSPACE tt WITH strategy_class=SimpleStrategy AND strategy_options:replication_factor=1; cqlsh USE tt; cqlsh:tt CREATE TABLE breakable ( ... dt timestamp, ... id timeuuid, ... metadata text, ... PRIMARY KEY (dt, id) ... ); cqlsh:tt Then changing to LCS using the CLI [default@unknown] use tt; Authenticated to keyspace: tt [default@tt] update column family breakable with compaction_strategy=LeveledCompactionStrategy; org.apache.thrift.transport.TTransportException And then trying to view the table schema cqlsh:tt describe table breakable; 'NoneType' object has no attribute 'startswith' cqlsh:tt Restarting cassandra causes an NPE ERROR 17:10:53,487 Exception encountered during startup java.lang.NullPointerException at org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167) at org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124) at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77) at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97) at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35) at org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87) at org.apache.cassandra.config.ColumnDefinition.fromSchema(ColumnDefinition.java:256) at org.apache.cassandra.config.CFMetaData.addColumnDefinitionSchema(CFMetaData.java:1293) at org.apache.cassandra.config.CFMetaData.fromSchema(CFMetaData.java:1225) at org.apache.cassandra.config.KSMetaData.deserializeColumnFamilies(KSMetaData.java:294) at org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:275) at org.apache.cassandra.db.DefsTable.loadFromTable(DefsTable.java:158) at org.apache.cassandra.config.DatabaseDescriptor.loadSchemas(DatabaseDescriptor.java:535) at org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:182) at org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:353) at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:106) java.lang.NullPointerException at org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167) at org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124) at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77) at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97) at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35) at org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87) at org.apache.cassandra.config.ColumnDefinition.fromSchema(ColumnDefinition.java:256) at org.apache.cassandra.config.CFMetaData.addColumnDefinitionSchema(CFMetaData.java:1293) at org.apache.cassandra.config.CFMetaData.fromSchema(CFMetaData.java:1225) at org.apache.cassandra.config.KSMetaData.deserializeColumnFamilies(KSMetaData.java:294) at org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:275) at org.apache.cassandra.db.DefsTable.loadFromTable(DefsTable.java:158) at org.apache.cassandra.config.DatabaseDescriptor.loadSchemas(DatabaseDescriptor.java:535) at org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:182) at org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:353) at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:106) Exception encountered during startup: null -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4496) NPE on creating secondary index
[
https://issues.apache.org/jira/browse/CASSANDRA-4496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13429647#comment-13429647
]
David Semeria commented on CASSANDRA-4496:
--
It would appear that it's index_name that's causing the problem:
The final cli command throws exactly the same NPE in core as described in the
OP.
[default@test] create column family basic
... with comparator='org.jellyfish.core.db.cassandra.JNameComparator'
... and column_metadata=[{column_name: id, validation_class:
'org.jellyfish.core.db.cassandra.JValueComparator'}];
fc9fa3e4-db1b-3860-aa60-667462f258b1
Waiting for schema agreement...
... schemas agree across the cluster
[default@test]
[default@test]
[default@test] describe;
Keyspace: test:
Replication Strategy: org.apache.cassandra.locator.NetworkTopologyStrategy
Durable Writes: true
Options: [datacenter1:1]
Column Families:
ColumnFamily: basic
Key Validation Class: org.apache.cassandra.db.marshal.BytesType
Default column value validator: org.apache.cassandra.db.marshal.BytesType
Columns sorted by: org.jellyfish.core.db.cassandra.JNameComparator
GC grace seconds: 864000
Compaction min/max thresholds: 4/32
Read repair chance: 0.1
DC Local Read repair chance: 0.0
Replicate on write: true
Caching: KEYS_ONLY
Bloom Filter FP chance: default
Built indexes: []
Column Metadata:
Column Name: id
Validation Class: org.jellyfish.core.db.cassandra.JValueComparator
Column Name:
Validation Class: org.jellyfish.core.db.cassandra.JValueComparator
Compaction Strategy:
org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy
Compression Options:
sstable_compression: org.apache.cassandra.io.compress.SnappyCompressor
[default@test]
[default@test]
[default@test]
[default@test] create column family indexed1
... with comparator='org.jellyfish.core.db.cassandra.JNameComparator'
... and column_metadata=[{column_name: id, validation_class:
'org.jellyfish.core.db.cassandra.JValueComparator', index_type: KEYS}];
1332a21e-d716-343d-bc54-04ac020c6300
Waiting for schema agreement...
... schemas agree across the cluster
[default@test]
[default@test]
[default@test] describe;
Keyspace: test:
Replication Strategy: org.apache.cassandra.locator.NetworkTopologyStrategy
Durable Writes: true
Options: [datacenter1:1]
Column Families:
ColumnFamily: basic
Key Validation Class: org.apache.cassandra.db.marshal.BytesType
Default column value validator: org.apache.cassandra.db.marshal.BytesType
Columns sorted by: org.jellyfish.core.db.cassandra.JNameComparator
GC grace seconds: 864000
Compaction min/max thresholds: 4/32
Read repair chance: 0.1
DC Local Read repair chance: 0.0
Replicate on write: true
Caching: KEYS_ONLY
Bloom Filter FP chance: default
Built indexes: []
Column Metadata:
Column Name:
Validation Class: org.jellyfish.core.db.cassandra.JValueComparator
Column Name:
Validation Class: org.jellyfish.core.db.cassandra.JValueComparator
Compaction Strategy:
org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy
Compression Options:
sstable_compression: org.apache.cassandra.io.compress.SnappyCompressor
ColumnFamily: indexed1
Key Validation Class: org.apache.cassandra.db.marshal.BytesType
Default column value validator: org.apache.cassandra.db.marshal.BytesType
Columns sorted by: org.jellyfish.core.db.cassandra.JNameComparator
GC grace seconds: 864000
Compaction min/max thresholds: 4/32
Read repair chance: 0.1
DC Local Read repair chance: 0.0
Replicate on write: true
Caching: KEYS_ONLY
Bloom Filter FP chance: default
Built indexes: [indexed1.indexed1_id_idx]
Column Metadata:
Column Name:
Validation Class: org.jellyfish.core.db.cassandra.JValueComparator
Index Name: indexed1_id_idx
Index Type: KEYS
Compaction Strategy:
org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy
Compression Options:
sstable_compression: org.apache.cassandra.io.compress.SnappyCompressor
[default@test]
[default@test]
[default@test] create column family indexed2
... with comparator='org.jellyfish.core.db.cassandra.JNameComparator'
... and column_metadata=[{column_name:id2, validation_class:
'org.jellyfish.core.db.cassandra.JValueComparator', index_type: KEYS,
index_name:id2}];
org.apache.thrift.transport.TTransportException
NPE on creating secondary index
---
Key: CASSANDRA-4496
URL: https://issues.apache.org/jira/browse/CASSANDRA-4496
Project: Cassandra
Issue Type: Bug
[jira] [Updated] (CASSANDRA-4496) NPE on creating secondary index
[
https://issues.apache.org/jira/browse/CASSANDRA-4496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-4496:
--
Reviewer: jbellis
Assignee: Pavel Yaskevich
NPE on creating secondary index
---
Key: CASSANDRA-4496
URL: https://issues.apache.org/jira/browse/CASSANDRA-4496
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.2, 1.1.3
Environment: Ubuntu 12.4
Linux 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6 14:25:57 UTC 2012 x86_64
x86_64 x86_64 GNU/Linux
java version 1.7.0
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode)
Reporter: David Semeria
Assignee: Pavel Yaskevich
The following code has been working fine up to and including 1.0.x
public static String createIndexedColumnFamily(String cf){
Cluster cluster = HectorConfig.cluster;
ComparatorType ctName =
ComparatorType.getByClassName(JNameComparator.class.getName());
try{
cluster.dropColumnFamily(HectorConfig.dfltKeyspaceName, cf );
} catch (Exception e){}
ListColumnDefinition cdL = new ArrayListColumnDefinition();
BasicColumnDefinition cd;
cd = new BasicColumnDefinition();
cd.setName(ss.toByteBuffer(id));
cd.setIndexName(id);
cd.setIndexType(ColumnIndexType.KEYS);
cd.setValidationClass(JValueComparator.class.getName());
cdL.add(cd);
ThriftCfDef cfd= new ThriftCfDef(HectorConfig.dfltKeyspaceName, cf,
ctName, cdL);
cfd.setKeyValidationClass(ComparatorType.UTF8TYPE.getClassName());
cfd.setDefaultValidationClass(JValueComparator.class.getName());
cluster.addColumnFamily(cfd);
return created: + cf;
}
}
I'm inclined to exclude the presence of the custom comparator since:
(1) there is no issue using it if the cf doesn't have a secondary index
(2) the stack trace (see below) doesn't include the comparator
The above code throws the following error in Cassandra 1.1.2 and 1.1.3
david@vlap1:~/opt/cassandra$ sudo bin/cassandra -f
xss = -ea -javaagent:/usr/share/cassandra/lib/jamm-0.2.5.jar
-XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -Xms128M -Xmx128M
-Xmn32M -XX:+HeapDumpOnOutOfMemoryError -Xss160k
INFO 23:15:31,333 Logging initialized
INFO 23:15:31,337 JVM vendor/version: Java HotSpot(TM) 64-Bit Server VM/1.7.0
INFO 23:15:31,338 Heap size: 130875392/130875392
INFO 23:15:31,338 Classpath:
/etc/cassandra:/usr/share/cassandra/lib/antlr-3.2.jar:/usr/share/cassandra/lib/avro-1.4.0-fixes.jar:/usr/share/cassandra/lib/avro-1.4.0-sources-fixes.jar:/usr/share/cassandra/lib/commons-cli-1.1.jar:/usr/share/cassandra/lib/commons-codec-1.2.jar:/usr/share/cassandra/lib/commons-lang-2.4.jar:/usr/share/cassandra/lib/compress-lzf-0.8.4.jar:/usr/share/cassandra/lib/concurrentlinkedhashmap-lru-1.3.jar:/usr/share/cassandra/lib/guava-r08.jar:/usr/share/cassandra/lib/hector-core-1.0-3.jar:/usr/share/cassandra/lib/high-scale-lib-1.1.2.jar:/usr/share/cassandra/lib/jackson-core-asl-1.9.2.jar:/usr/share/cassandra/lib/jackson-mapper-asl-1.9.2.jar:/usr/share/cassandra/lib/jamm-0.2.5.jar:/usr/share/cassandra/lib/jellyfish.jar:/usr/share/cassandra/lib/jline-0.9.94.jar:/usr/share/cassandra/lib/json-simple-1.1.jar:/usr/share/cassandra/lib/libthrift-0.7.0.jar:/usr/share/cassandra/lib/log4j-1.2.16.jar:/usr/share/cassandra/lib/metrics-core-2.0.3.jar:/usr/share/cassandra/lib/servlet-api-2.5-20081211.jar:/usr/share/cassandra/lib/slf4j-api-1.6.1.jar:/usr/share/cassandra/lib/slf4j-log4j12-1.6.1.jar:/usr/share/cassandra/lib/snakeyaml-1.6.jar:/usr/share/cassandra/lib/snappy-java-1.0.4.1.jar:/usr/share/cassandra/lib/snaptree-0.1.jar:/usr/share/cassandra/apache-cassandra-1.1.2.jar:/usr/share/cassandra/apache-cassandra-thrift-1.1.2.jar:/usr/share/cassandra/apache-cassandra.jar:/usr/share/cassandra/stress.jar:/usr/share/cassandra/lib/jamm-0.2.5.jar
INFO 23:15:31,340 JNA not found. Native methods will be disabled.
INFO 23:15:31,351 Loading settings from file:/etc/cassandra/cassandra.yaml
INFO 23:15:31,566 DiskAccessMode 'auto' determined to be mmap,
indexAccessMode is mmap
INFO 23:15:31,875 Global memtable threshold is enabled at 41MB
INFO 23:15:32,380 Initializing key cache with capacity of 6 MBs.
INFO 23:15:32,394 Scheduling key cache save to each 14400 seconds (going to
save all keys).
INFO 23:15:32,395 Initializing row cache with capacity of 0 MBs and provider
org.apache.cassandra.cache.SerializingCacheProvider
INFO 23:15:32,400 Scheduling row cache save to each 0 seconds (going to save
all keys).
INFO 23:15:32,661 Couldn't detect any schema definitions in local storage.
INFO 23:15:32,665 Found table data in data directories. Consider using the
CLI to define your schema.
INFO
