[jira] [Comment Edited] (CASSANDRA-8072) Exception during startup: Unable to gossip with any seeds
[ https://issues.apache.org/jira/browse/CASSANDRA-8072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14742914#comment-14742914 ] Steven Lowenthal edited comment on CASSANDRA-8072 at 9/14/15 4:49 AM: -- I can easily reproduce this with my automated launcher I even tried to better randomize when non-seed nodes come in to join. I recently noticed that the seed node has a socket stuck in CLOSE_WAIT for the nodes that report can't gossip with any seeds. Perhaps the solution lies in ensuring that both ends of the connection properly close the connection. It's likely the client (the node asking to join) exceptions out and dies without elegantly closing the connection. See Screenshot. Also well-known port afs3-fileserver is 7000. was (Author: slowenthal): I can easily reproduce this with my automated launcher I even tried to better randomize when non-seed nodes come in to join. I recently noticed that the seed node has a socket stuck in CLOSE_WAIT for the nodes that report can't gossip with any seeds. Perhaps the solution lies in ensuring that both ends of the connection properly close the connection. It's likely the client (the node asking to join) exceptions out and dies without elegantly closing the connection. > Exception during startup: Unable to gossip with any seeds > - > > Key: CASSANDRA-8072 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8072 > Project: Cassandra > Issue Type: Bug >Reporter: Ryan Springer >Assignee: Brandon Williams > Fix For: 2.1.x > > Attachments: cas-dev-dt-01-uw1-cassandra-seed01_logs.tar.bz2, > cas-dev-dt-01-uw1-cassandra-seed02_logs.tar.bz2, > cas-dev-dt-01-uw1-cassandra02_logs.tar.bz2, > casandra-system-log-with-assert-patch.log, screenshot-1.png, > trace_logs.tar.bz2 > > > When Opscenter 4.1.4 or 5.0.1 tries to provision a 2-node DSC 2.0.10 cluster > in either ec2 or locally, an error occurs sometimes with one of the nodes > refusing to start C*. The error in the /var/log/cassandra/system.log is: > ERROR [main] 2014-10-06 15:54:52,292 CassandraDaemon.java (line 513) > Exception encountered during startup > java.lang.RuntimeException: Unable to gossip with any seeds > at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1200) > at > org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:444) > at > org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:655) > at > org.apache.cassandra.service.StorageService.initServer(StorageService.java:609) > at > org.apache.cassandra.service.StorageService.initServer(StorageService.java:502) > at > org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:378) > at > org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:496) > at > org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:585) > INFO [StorageServiceShutdownHook] 2014-10-06 15:54:52,326 Gossiper.java > (line 1279) Announcing shutdown > INFO [StorageServiceShutdownHook] 2014-10-06 15:54:54,326 > MessagingService.java (line 701) Waiting for messaging service to quiesce > INFO [ACCEPT-localhost/127.0.0.1] 2014-10-06 15:54:54,327 > MessagingService.java (line 941) MessagingService has terminated the accept() > thread > This errors does not always occur when provisioning a 2-node cluster, but > probably around half of the time on only one of the nodes. I haven't been > able to reproduce this error with DSC 2.0.9, and there have been no code or > definition file changes in Opscenter. > I can reproduce locally with the above steps. I'm happy to test any proposed > fixes since I'm the only person able to reproduce reliably so far. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8072) Exception during startup: Unable to gossip with any seeds
[ https://issues.apache.org/jira/browse/CASSANDRA-8072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14742914#comment-14742914 ] Steven Lowenthal commented on CASSANDRA-8072: - I can easily reproduce this with my automated launcher I even tried to better randomize when non-seed nodes come in to join. I recently noticed that the seed node has a socket stuck in CLOSE_WAIT for the nodes that report can't gossip with any seeds. Perhaps the solution lies in ensuring that both ends of the connection properly close the connection. It's likely the client (the node asking to join) exceptions out and dies without elegantly closing the connection. > Exception during startup: Unable to gossip with any seeds > - > > Key: CASSANDRA-8072 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8072 > Project: Cassandra > Issue Type: Bug >Reporter: Ryan Springer >Assignee: Brandon Williams > Fix For: 2.1.x > > Attachments: cas-dev-dt-01-uw1-cassandra-seed01_logs.tar.bz2, > cas-dev-dt-01-uw1-cassandra-seed02_logs.tar.bz2, > cas-dev-dt-01-uw1-cassandra02_logs.tar.bz2, > casandra-system-log-with-assert-patch.log, trace_logs.tar.bz2 > > > When Opscenter 4.1.4 or 5.0.1 tries to provision a 2-node DSC 2.0.10 cluster > in either ec2 or locally, an error occurs sometimes with one of the nodes > refusing to start C*. The error in the /var/log/cassandra/system.log is: > ERROR [main] 2014-10-06 15:54:52,292 CassandraDaemon.java (line 513) > Exception encountered during startup > java.lang.RuntimeException: Unable to gossip with any seeds > at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1200) > at > org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:444) > at > org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:655) > at > org.apache.cassandra.service.StorageService.initServer(StorageService.java:609) > at > org.apache.cassandra.service.StorageService.initServer(StorageService.java:502) > at > org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:378) > at > org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:496) > at > org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:585) > INFO [StorageServiceShutdownHook] 2014-10-06 15:54:52,326 Gossiper.java > (line 1279) Announcing shutdown > INFO [StorageServiceShutdownHook] 2014-10-06 15:54:54,326 > MessagingService.java (line 701) Waiting for messaging service to quiesce > INFO [ACCEPT-localhost/127.0.0.1] 2014-10-06 15:54:54,327 > MessagingService.java (line 941) MessagingService has terminated the accept() > thread > This errors does not always occur when provisioning a 2-node cluster, but > probably around half of the time on only one of the nodes. I haven't been > able to reproduce this error with DSC 2.0.9, and there have been no code or > definition file changes in Opscenter. > I can reproduce locally with the above steps. I'm happy to test any proposed > fixes since I'm the only person able to reproduce reliably so far. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8072) Exception during startup: Unable to gossip with any seeds
[ https://issues.apache.org/jira/browse/CASSANDRA-8072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Lowenthal updated CASSANDRA-8072: Attachment: screenshot-1.png > Exception during startup: Unable to gossip with any seeds > - > > Key: CASSANDRA-8072 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8072 > Project: Cassandra > Issue Type: Bug >Reporter: Ryan Springer >Assignee: Brandon Williams > Fix For: 2.1.x > > Attachments: cas-dev-dt-01-uw1-cassandra-seed01_logs.tar.bz2, > cas-dev-dt-01-uw1-cassandra-seed02_logs.tar.bz2, > cas-dev-dt-01-uw1-cassandra02_logs.tar.bz2, > casandra-system-log-with-assert-patch.log, screenshot-1.png, > trace_logs.tar.bz2 > > > When Opscenter 4.1.4 or 5.0.1 tries to provision a 2-node DSC 2.0.10 cluster > in either ec2 or locally, an error occurs sometimes with one of the nodes > refusing to start C*. The error in the /var/log/cassandra/system.log is: > ERROR [main] 2014-10-06 15:54:52,292 CassandraDaemon.java (line 513) > Exception encountered during startup > java.lang.RuntimeException: Unable to gossip with any seeds > at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1200) > at > org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:444) > at > org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:655) > at > org.apache.cassandra.service.StorageService.initServer(StorageService.java:609) > at > org.apache.cassandra.service.StorageService.initServer(StorageService.java:502) > at > org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:378) > at > org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:496) > at > org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:585) > INFO [StorageServiceShutdownHook] 2014-10-06 15:54:52,326 Gossiper.java > (line 1279) Announcing shutdown > INFO [StorageServiceShutdownHook] 2014-10-06 15:54:54,326 > MessagingService.java (line 701) Waiting for messaging service to quiesce > INFO [ACCEPT-localhost/127.0.0.1] 2014-10-06 15:54:54,327 > MessagingService.java (line 941) MessagingService has terminated the accept() > thread > This errors does not always occur when provisioning a 2-node cluster, but > probably around half of the time on only one of the nodes. I haven't been > able to reproduce this error with DSC 2.0.9, and there have been no code or > definition file changes in Opscenter. > I can reproduce locally with the above steps. I'm happy to test any proposed > fixes since I'm the only person able to reproduce reliably so far. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9083) cqlsh COPY functionality doesn't work together with SOURCE or with cqlsh -f
[
https://issues.apache.org/jira/browse/CASSANDRA-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14563810#comment-14563810
]
Steven Lowenthal commented on CASSANDRA-9083:
-
This is more serious than it looks as it causes everyone's existing scripts to
fail. Let's make it major.
cqlsh COPY functionality doesn't work together with SOURCE or with cqlsh -f
---
Key: CASSANDRA-9083
URL: https://issues.apache.org/jira/browse/CASSANDRA-9083
Project: Cassandra
Issue Type: Bug
Components: Tools
Environment: 2.1.3
Reporter: Joseph Chu
Assignee: Tyler Hobbs
Priority: Minor
Labels: cqlsh
Fix For: 2.1.x
Executing a COPY command from an external file using the cqlsh -f or the
SOURCE command results in the error:
filename.cql:7:descriptor 'lower' requires a 'str' object but received a
'unicode'
Looks like there was a change in the cqlsh code from 2.1.2 to 2.1.3 which
makes use of codecs.open() instead of open(), which returns a unicode object.
The offending line of code that returns the error seems to be in cqlsh, line
1415:
copyoptnames = map(str.lower, parsed.get_binding('optnames', ()))
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-8142) prevent the command cassandra start from starting a cluster
Steven Lowenthal created CASSANDRA-8142: --- Summary: prevent the command cassandra start from starting a cluster Key: CASSANDRA-8142 URL: https://issues.apache.org/jira/browse/CASSANDRA-8142 Project: Cassandra Issue Type: Improvement Components: Packaging Reporter: Steven Lowenthal Students often type sudo service cassandra start wrong, and type sudo cassandra start. Running a package installation as root messes up their environments. since start is not a valid option on the cassandra command, we should block cassandra from starting. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-7350) Decommissioning nodes borks the seed node - can't add additional nodes
Steven Lowenthal created CASSANDRA-7350: --- Summary: Decommissioning nodes borks the seed node - can't add additional nodes Key: CASSANDRA-7350 URL: https://issues.apache.org/jira/browse/CASSANDRA-7350 Project: Cassandra Issue Type: Bug Components: Core Environment: Ubuntu using the auto-clustering AMI Reporter: Steven Lowenthal 1) Launch a 4 node cluster - I used the auto-clustering AMI (you get nodes 0-3) 2) decommission that last 2 nodes (nodes , leaving a 2 node cluster) 3) wipe the data directories from node 2 4) bootstrap node2 - it won't join unable to gossip with any seeds. If you bootstrap the node a second time, it will join. However if you try to bootstrap node 3, it will also fail. I discovered that bouncing the seed node fixes the problem. I think it cropped up in 2.0.7. Error: ERROR [main] 2014-06-03 21:52:46,649 CassandraDaemon.java (line 497) Exception encountered during startup java.lang.RuntimeException: Unable to gossip with any seeds at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1193) at org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:447) at org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:656) at org.apache.cassandra.service.StorageService.initServer(StorageService.java:612) at org.apache.cassandra.service.StorageService.initServer(StorageService.java:505) at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:362) at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:480) at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:569) ERROR [StorageServiceShutdownHook] 2014-06-03 21:52:46,741 CassandraDaemon.java (line 198) Exception in thread Thread[StorageServi -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CASSANDRA-7256) Error when dropping keyspace.
Steven Lowenthal created CASSANDRA-7256:
---
Summary: Error when dropping keyspace.
Key: CASSANDRA-7256
URL: https://issues.apache.org/jira/browse/CASSANDRA-7256
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: ubuntu 3 nodes (had 3 more in 2nd datacenter but removed
it)
Reporter: Steven Lowenthal
created a 3 node datacenter called existing.
ran cassandra-stress:
cassandra-stress -R NetworkTopologyStrategy -O existing:2 -d existing0 -n
200 -k
Added a 2nd datacenter called new with 3 nodes started it with auto_bootstrap:
false
alter keyspace Keyspace1 with replication =
{'class':'NetworkTopologyStrategy','existing':2,'new':2};
I then discovered that cassandra-stress --operation=read failed with
LOCAL_QUORUM if a node was down in the local datacenter - this occured in both,
but should not have, so decided to try again.
I shut down the new datacenter and removed all 3 nodes. I then tried to drop
the Keyspace1 keyspace. cqlsh disconnected, and the log shows the error below.
ERROR [MigrationStage:1] 2014-05-16 23:57:03,085 CassandraDaemon.java (line
198) Exception in thread Thread[MigrationStage:1,5,main]
java.lang.IllegalStateException: One row required, 0 found
at org.apache.cassandra.cql3.UntypedResultSet.one(UntypedResultSet.java:53)
at org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:263)
at org.apache.cassandra.db.DefsTables.mergeKeyspaces(DefsTables.java:227)
at org.apache.cassandra.db.DefsTables.mergeSchema(DefsTables.java:182)
at
org.apache.cassandra.service.MigrationManager$2.runMayThrow(MigrationManager.java:303)
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:744)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CASSANDRA-6986) snapshot fails with SSTable not found if table has already been restored
Steven Lowenthal created CASSANDRA-6986: --- Summary: snapshot fails with SSTable not found if table has already been restored Key: CASSANDRA-6986 URL: https://issues.apache.org/jira/browse/CASSANDRA-6986 Project: Cassandra Issue Type: Bug Components: Core Environment: C* 2.0.6 Reporter: Steven Lowenthal I seem to be running into a weird restore issue. I load a database with sstableloader, and then take a snapshot of the keyspace. I then truncate the tables in the keyspace, replace the sstables from the snapshot, and refresh everything. It seems to work fine. Of course the sstables get renumbered. I then try to create a new backup of the keyspace, and this happens on one of the tables on one of the nodes. (and the sstable has been renumbered): Exception in thread main java.lang.RuntimeException: Tried to hard link to file that does not exist /raid0/cassandra/data/stock/trades/stock-trades-jb-18-Data.db -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CASSANDRA-6819) The command nodetool setcompactionthroughput sometimes takes a long time to take effect
Steven Lowenthal created CASSANDRA-6819: --- Summary: The command nodetool setcompactionthroughput sometimes takes a long time to take effect Key: CASSANDRA-6819 URL: https://issues.apache.org/jira/browse/CASSANDRA-6819 Project: Cassandra Issue Type: Bug Components: Core Reporter: Steven Lowenthal It's often necessary to throttle a large compaction. When the nodetool setcompactionthroughput command is issued, the setting doesn't seem to take hold until another compaction starts, which may be some time on a bungled node. This command should take hold immediately. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6190) Cassandra 2.0 won't start up with Java 7u40 with Client JVM. (works on Server JVM, and both JVMs 7u25)
[ https://issues.apache.org/jira/browse/CASSANDRA-6190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13796439#comment-13796439 ] Steven Lowenthal commented on CASSANDRA-6190: - Here is a response from Oracle: Hi Steve, I just wanted to close the loop on the bug you filled about UseCondCardMark not being available with the client JVM in 7u40. The issue is that UseCondCardMark was never really available in client. It was a NOP, and in 7u40 we moved the flag to work only with server as it should be. Sorry for the confusion. -- Azeem Jiva @javawithjiva Cassandra 2.0 won't start up with Java 7u40 with Client JVM. (works on Server JVM, and both JVMs 7u25) --- Key: CASSANDRA-6190 URL: https://issues.apache.org/jira/browse/CASSANDRA-6190 Project: Cassandra Issue Type: Bug Components: Config Environment: Ubuntu 13.04 32- and 64-bit JDK 7u40 (tried JRE 7u25) Reporter: Steven Lowenthal Assignee: Brandon Williams Attachments: 6190.txt Java 7u40 on some platforms do not recognize the the -XX:+UseCondCardMark JVM option. 7u40 on Macintosh works correctly, If I use the tarball 7u40 version of 7, we encounter the error below. I tried 7u25 (the previous release) and it functioned correctly. ubuntu@ubuntu:~$ Unrecognized VM option 'UseCondCardMark' Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6190) Cassandra 2.0 won't start up with Java 7u40 with Client JVM. (works on Server JVM, and both JVMs 7u25)
[ https://issues.apache.org/jira/browse/CASSANDRA-6190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13796442#comment-13796442 ] Steven Lowenthal commented on CASSANDRA-6190: - Also 7u45 is out today, and it exhibits the same problem. Cassandra 2.0 won't start up with Java 7u40 with Client JVM. (works on Server JVM, and both JVMs 7u25) --- Key: CASSANDRA-6190 URL: https://issues.apache.org/jira/browse/CASSANDRA-6190 Project: Cassandra Issue Type: Bug Components: Config Environment: Ubuntu 13.04 32- and 64-bit JDK 7u40 (tried JRE 7u25) Reporter: Steven Lowenthal Assignee: Brandon Williams Attachments: 6190.txt Java 7u40 on some platforms do not recognize the the -XX:+UseCondCardMark JVM option. 7u40 on Macintosh works correctly, If I use the tarball 7u40 version of 7, we encounter the error below. I tried 7u25 (the previous release) and it functioned correctly. ubuntu@ubuntu:~$ Unrecognized VM option 'UseCondCardMark' Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6190) Cassandra 2.0 won't start up on some platforms with Java 7u40
[ https://issues.apache.org/jira/browse/CASSANDRA-6190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13794829#comment-13794829 ] Steven Lowenthal commented on CASSANDRA-6190: - It does work on windows - set JAVA_HOME manually to a 7u40 home, and add the JVM option to cassandra.bat. Verified with jconsole. Cassandra 2.0 won't start up on some platforms with Java 7u40 - Key: CASSANDRA-6190 URL: https://issues.apache.org/jira/browse/CASSANDRA-6190 Project: Cassandra Issue Type: Bug Components: Config Environment: Ubuntu 13.04 32- and 64-bit JDK 7u40 (tried JRE 7u25) Reporter: Steven Lowenthal Java 7u40 on some platforms do not recognize the the -XX:+UseCondCardMark JVM option. 7u40 on Macintosh works correctly, If I use the tarball 7u40 version of 7, we encounter the error below. I tried 7u25 (the previous release) and it functioned correctly. ubuntu@ubuntu:~$ Unrecognized VM option 'UseCondCardMark' Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6190) Cassandra 2.0 won't start up on some platforms with Java 7u40
[
https://issues.apache.org/jira/browse/CASSANDRA-6190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13794864#comment-13794864
]
Steven Lowenthal commented on CASSANDRA-6190:
-
Mystery Solved: In 7u40, the option is missing in the Client JVM. In 7u25,
it's available in both the client and server JVM.
ubuntu@ubuntu:~/Downloads$ cd jre1.7.0_40/
ubuntu@ubuntu:~/Downloads/jre1.7.0_40$ find . -type f -exec grep UseCondCard {}
+
Binary file ./lib/i386/server/libjvm.so matches
ubuntu@ubuntu:~/Downloads/jre1.7.0_25$ find . -type f -exec grep UseCondCard {}
+
Binary file ./lib/i386/server/libjvm.so matches
Binary file ./lib/i386/client/libjvm.so matches
ubuntu@ubuntu:~/Downloads/jre1.7.0_25$
Cassandra 2.0 won't start up on some platforms with Java 7u40
-
Key: CASSANDRA-6190
URL: https://issues.apache.org/jira/browse/CASSANDRA-6190
Project: Cassandra
Issue Type: Bug
Components: Config
Environment: Ubuntu 13.04 32- and 64-bit JDK 7u40 (tried JRE 7u25)
Reporter: Steven Lowenthal
Java 7u40 on some platforms do not recognize the the -XX:+UseCondCardMark JVM
option. 7u40 on Macintosh works correctly, If I use the tarball 7u40
version of 7, we encounter the error below. I tried 7u25 (the previous
release) and it functioned correctly.
ubuntu@ubuntu:~$ Unrecognized VM option 'UseCondCardMark'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CASSANDRA-6190) Cassandra 2.0 won't start up with Java 7u40 with Client JVM. (works on Server JVM, and both JVMs 7u25)
[ https://issues.apache.org/jira/browse/CASSANDRA-6190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13794911#comment-13794911 ] Steven Lowenthal commented on CASSANDRA-6190: - Oracle Bug report filed 9007478 Dear Java Developer, Thank you for reporting this issue. We have determined that this report is a new bug and have entered the bug into our bug tracking system under Bug Id: 9007478 . You can look for related issues on the Java Bug Database at http://bugs.sun.com. We will try to process all newly posted bugs in a timely manner, but we make no promises about the amount of time in which a bug will be fixed. If you just reported a bug that could have a major impact on your project, consider using one of the technical support offerings available at Oracle Support. Thanks again for your submission! Regards, Java Developer Support Cassandra 2.0 won't start up with Java 7u40 with Client JVM. (works on Server JVM, and both JVMs 7u25) --- Key: CASSANDRA-6190 URL: https://issues.apache.org/jira/browse/CASSANDRA-6190 Project: Cassandra Issue Type: Bug Components: Config Environment: Ubuntu 13.04 32- and 64-bit JDK 7u40 (tried JRE 7u25) Reporter: Steven Lowenthal Java 7u40 on some platforms do not recognize the the -XX:+UseCondCardMark JVM option. 7u40 on Macintosh works correctly, If I use the tarball 7u40 version of 7, we encounter the error below. I tried 7u25 (the previous release) and it functioned correctly. ubuntu@ubuntu:~$ Unrecognized VM option 'UseCondCardMark' Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6190) Cassandra 2.0 won't start up with Java 7u40 with Client JVM. (works on Server JVM, and both JVMs 7u25)
[ https://issues.apache.org/jira/browse/CASSANDRA-6190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13794916#comment-13794916 ] Steven Lowenthal commented on CASSANDRA-6190: - It looks like java defaults to client if the machine has only 1 core. Our training VM was created with a single core. Cassandra 2.0 won't start up with Java 7u40 with Client JVM. (works on Server JVM, and both JVMs 7u25) --- Key: CASSANDRA-6190 URL: https://issues.apache.org/jira/browse/CASSANDRA-6190 Project: Cassandra Issue Type: Bug Components: Config Environment: Ubuntu 13.04 32- and 64-bit JDK 7u40 (tried JRE 7u25) Reporter: Steven Lowenthal Java 7u40 on some platforms do not recognize the the -XX:+UseCondCardMark JVM option. 7u40 on Macintosh works correctly, If I use the tarball 7u40 version of 7, we encounter the error below. I tried 7u25 (the previous release) and it functioned correctly. ubuntu@ubuntu:~$ Unrecognized VM option 'UseCondCardMark' Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CASSANDRA-6190) Cassandra 2.0 won't start up on some platforms with Java 7u40
Steven Lowenthal created CASSANDRA-6190: --- Summary: Cassandra 2.0 won't start up on some platforms with Java 7u40 Key: CASSANDRA-6190 URL: https://issues.apache.org/jira/browse/CASSANDRA-6190 Project: Cassandra Issue Type: Bug Components: Config Environment: Ubuntu 13.04 32- and 64-bit JDK 7u40 (tried JRE 7u25) Reporter: Steven Lowenthal Java 7u40 on some platforms do not recognize the the -XX:+UseCondCardMark JVM option. 7u40 on Macintosh works correctly, If I use the tarball 7u40 version of 7, we encounter the error below. I tried 7u25 (the previous release) and it functioned correctly. ubuntu@ubuntu:~$ Unrecognized VM option 'UseCondCardMark' Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6190) Cassandra 2.0 won't start up on some platforms with Java 7u40
[ https://issues.apache.org/jira/browse/CASSANDRA-6190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793731#comment-13793731 ] Steven Lowenthal commented on CASSANDRA-6190: - This is Oracle JDK. It works on OSX. I checked system.log and jconsole on mac to ensure that it's picked up, and we are running 7u40, and both are true. Cassandra 2.0 won't start up on some platforms with Java 7u40 - Key: CASSANDRA-6190 URL: https://issues.apache.org/jira/browse/CASSANDRA-6190 Project: Cassandra Issue Type: Bug Components: Config Environment: Ubuntu 13.04 32- and 64-bit JDK 7u40 (tried JRE 7u25) Reporter: Steven Lowenthal Java 7u40 on some platforms do not recognize the the -XX:+UseCondCardMark JVM option. 7u40 on Macintosh works correctly, If I use the tarball 7u40 version of 7, we encounter the error below. I tried 7u25 (the previous release) and it functioned correctly. ubuntu@ubuntu:~$ Unrecognized VM option 'UseCondCardMark' Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6190) Cassandra 2.0 won't start up on some platforms with Java 7u40
[ https://issues.apache.org/jira/browse/CASSANDRA-6190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793799#comment-13793799 ] Steven Lowenthal commented on CASSANDRA-6190: - I've even tried it by explicitly setting JAVA_HOME to point at my various javas. Remember - if we aren't using Java 7, we don't fall into the code that adds that parameter. Java 7 gets put in the system.log. Cassandra 2.0 won't start up on some platforms with Java 7u40 - Key: CASSANDRA-6190 URL: https://issues.apache.org/jira/browse/CASSANDRA-6190 Project: Cassandra Issue Type: Bug Components: Config Environment: Ubuntu 13.04 32- and 64-bit JDK 7u40 (tried JRE 7u25) Reporter: Steven Lowenthal Java 7u40 on some platforms do not recognize the the -XX:+UseCondCardMark JVM option. 7u40 on Macintosh works correctly, If I use the tarball 7u40 version of 7, we encounter the error below. I tried 7u25 (the previous release) and it functioned correctly. ubuntu@ubuntu:~$ Unrecognized VM option 'UseCondCardMark' Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6190) Cassandra 2.0 won't start up on some platforms with Java 7u40
[ https://issues.apache.org/jira/browse/CASSANDRA-6190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793875#comment-13793875 ] Steven Lowenthal commented on CASSANDRA-6190: - Here is a simple test. Not the FileNotFoundException is good - I ran C* with the wrong permissions, so that is the expected result. Unix Info: Linux ubuntu 3.8.0-19-generic #29-Ubuntu SMP Wed Apr 17 18:19:42 UTC 2013 i686 i686 i686 GNU/Linux u ubuntu@ubuntu:~$ export JAVA_HOME=~/Downloads/jre1.7.0_40/ ubuntu@ubuntu:~$ cassandra xss = -ea -javaagent:/usr/share/cassandra/lib/jamm-0.2.5.jar -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -Xms1024M -Xmx1024M -Xmn100M -XX:+HeapDumpOnOutOfMemoryError -Xss256k ubuntu@ubuntu:~$ Unrecognized VM option 'UseCondCardMark' Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. ubuntu@ubuntu:~$ export JAVA_HOME=~/Downloads/jre1.7.0_25/ ubuntu@ubuntu:~$ cassandra xss = -ea -javaagent:/usr/share/cassandra/lib/jamm-0.2.5.jar -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -Xms1024M -Xmx1024M -Xmn100M -XX:+HeapDumpOnOutOfMemoryError -Xss256k ubuntu@ubuntu:~$ log4j:ERROR setFile(null,true) call failed. java.io.FileNotFoundException: /var/log/cassandra/system.log (Permission denied) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.init(Unknown Source) Cassandra 2.0 won't start up on some platforms with Java 7u40 - Key: CASSANDRA-6190 URL: https://issues.apache.org/jira/browse/CASSANDRA-6190 Project: Cassandra Issue Type: Bug Components: Config Environment: Ubuntu 13.04 32- and 64-bit JDK 7u40 (tried JRE 7u25) Reporter: Steven Lowenthal Java 7u40 on some platforms do not recognize the the -XX:+UseCondCardMark JVM option. 7u40 on Macintosh works correctly, If I use the tarball 7u40 version of 7, we encounter the error below. I tried 7u25 (the previous release) and it functioned correctly. ubuntu@ubuntu:~$ Unrecognized VM option 'UseCondCardMark' Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-4366) add UseCondCardMark XX jvm settings on jdk 1.7
[ https://issues.apache.org/jira/browse/CASSANDRA-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793557#comment-13793557 ] Steven Lowenthal commented on CASSANDRA-4366: - I'm getting an error that the UseCondCardMark option is invalid on JDK 7u40. add UseCondCardMark XX jvm settings on jdk 1.7 -- Key: CASSANDRA-4366 URL: https://issues.apache.org/jira/browse/CASSANDRA-4366 Project: Cassandra Issue Type: Improvement Components: Packaging Affects Versions: 1.2.0 beta 1 Reporter: Dave Brosius Assignee: Dave Brosius Priority: Trivial Fix For: 1.2.2 Attachments: 4366.txt found by jbellis adding jvm extension setting UseCondCardMark as defined here http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7029167 for better lock handling especially on hotspot with multicore processors. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Reopened] (CASSANDRA-4366) add UseCondCardMark XX jvm settings on jdk 1.7
[ https://issues.apache.org/jira/browse/CASSANDRA-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Lowenthal reopened CASSANDRA-4366: - add UseCondCardMark XX jvm settings on jdk 1.7 -- Key: CASSANDRA-4366 URL: https://issues.apache.org/jira/browse/CASSANDRA-4366 Project: Cassandra Issue Type: Improvement Components: Packaging Affects Versions: 1.2.0 beta 1 Reporter: Dave Brosius Assignee: Dave Brosius Priority: Trivial Fix For: 1.2.2 Attachments: 4366.txt found by jbellis adding jvm extension setting UseCondCardMark as defined here http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7029167 for better lock handling especially on hotspot with multicore processors. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CASSANDRA-5766) The output of the describe command does not necessarily give you the right DDL to re-create the CF
Steven Lowenthal created CASSANDRA-5766:
---
Summary: The output of the describe command does not necessarily
give you the right DDL to re-create the CF
Key: CASSANDRA-5766
URL: https://issues.apache.org/jira/browse/CASSANDRA-5766
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 2.1
Reporter: Steven Lowenthal
If compression is not set for a CF, cqlsh omits the compression attribute.
When you replay that very same DDL, you get a CF with Snappy compression. This
may occur with other parameters. Perhaps describe should always show every
parameter in full. The absence of a setting is a setting. (Think of the arrow
in the FedEx logo).
Create a CF with cassandra-stress. cassandra-stress defaults to NO compression.
~/dse/resources/cassandra/tools/bin/cassandra-stress -S 100 -c 1 --num-keys 1
describe it
CREATE TABLE Standard1 (
key blob PRIMARY KEY,
C0 blob
) WITH COMPACT STORAGE AND
bloom_filter_fp_chance=0.01 AND
caching='KEYS_ONLY' AND
comment='' AND
dclocal_read_repair_chance=0.00 AND
gc_grace_seconds=864000 AND
read_repair_chance=0.10 AND
replicate_on_write='true' AND
populate_io_cache_on_flush='false' AND
compaction={'class': 'SizeTieredCompactionStrategy'};
replay it - I changed the cf name to standard2
describe the new CF:
CREATE TABLE standard2 (
key blob PRIMARY KEY,
C0 blob
) WITH COMPACT STORAGE AND
bloom_filter_fp_chance=0.01 AND
caching='KEYS_ONLY' AND
comment='' AND
dclocal_read_repair_chance=0.00 AND
gc_grace_seconds=864000 AND
read_repair_chance=0.10 AND
replicate_on_write='true' AND
populate_io_cache_on_flush='false' AND
compaction={'class': 'SizeTieredCompactionStrategy'} AND
compression={'sstable_compression': 'SnappyCompressor'};
--
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-5733) json2sstable can not read from a pipe even if -n and -s are specified.
[
https://issues.apache.org/jira/browse/CASSANDRA-5733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13705010#comment-13705010
]
Steven Lowenthal commented on CASSANDRA-5733:
-
I also add a tiny bit of code so if the filename is -, it will read from
stdin. (Follows the convention of tar and some other random tools). I'm now
spewing sstables like there's no tomorrow.
json2sstable can not read from a pipe even if -n and -s are specified.
--
Key: CASSANDRA-5733
URL: https://issues.apache.org/jira/browse/CASSANDRA-5733
Project: Cassandra
Issue Type: Improvement
Components: Tools
Affects Versions: 1.2.6
Reporter: Steven Lowenthal
Priority: Minor
SSTableImport.importSorted always opens the file twice even if the number of
keys are specifed. I changed this to only open the file a second time when
-n is not specified.
I moved the second parser = getparser ... call inside the if
(keyCountToImport == null) block.
if (keyCountToImport == null)
{
keyCountToImport = 0;
System.out.println(Counting keys to import, please wait...
(NOTE: to skip this use -n num_keys));
parser.nextToken(); // START_ARRAY
while (parser.nextToken() != null)
{
parser.skipChildren();
if (parser.getCurrentToken() == JsonToken.END_ARRAY)
break;
keyCountToImport++;
}
parser = getParser(jsonFile); // renewing parser only if we read
the file already - to support streaming.
}
--
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-5733) json2sstable can not read from a pipe even if -n and -s are specified.
[
https://issues.apache.org/jira/browse/CASSANDRA-5733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13705016#comment-13705016
]
Steven Lowenthal commented on CASSANDRA-5733:
-
Also, with these options, it's easy for the user to specify invalid
combinations of optsion like - for the file when -s -n isn't specified, etc.
To what extent do we want to be a nanny?
json2sstable can not read from a pipe even if -n and -s are specified.
--
Key: CASSANDRA-5733
URL: https://issues.apache.org/jira/browse/CASSANDRA-5733
Project: Cassandra
Issue Type: Improvement
Components: Tools
Affects Versions: 1.2.6
Reporter: Steven Lowenthal
Priority: Minor
Attachments: 5733.txt
SSTableImport.importSorted always opens the file twice even if the number of
keys are specifed. I changed this to only open the file a second time when
-n is not specified.
I moved the second parser = getparser ... call inside the if
(keyCountToImport == null) block.
if (keyCountToImport == null)
{
keyCountToImport = 0;
System.out.println(Counting keys to import, please wait...
(NOTE: to skip this use -n num_keys));
parser.nextToken(); // START_ARRAY
while (parser.nextToken() != null)
{
parser.skipChildren();
if (parser.getCurrentToken() == JsonToken.END_ARRAY)
break;
keyCountToImport++;
}
parser = getParser(jsonFile); // renewing parser only if we read
the file already - to support streaming.
}
--
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-5733) json2sstable can not read from a pipe even if -n and -s are specified.
[
https://issues.apache.org/jira/browse/CASSANDRA-5733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Lowenthal updated CASSANDRA-5733:
Attachment: 5733.txt
json2sstable can not read from a pipe even if -n and -s are specified.
--
Key: CASSANDRA-5733
URL: https://issues.apache.org/jira/browse/CASSANDRA-5733
Project: Cassandra
Issue Type: Improvement
Components: Tools
Affects Versions: 1.2.6
Reporter: Steven Lowenthal
Priority: Minor
Attachments: 5733.txt
SSTableImport.importSorted always opens the file twice even if the number of
keys are specifed. I changed this to only open the file a second time when
-n is not specified.
I moved the second parser = getparser ... call inside the if
(keyCountToImport == null) block.
if (keyCountToImport == null)
{
keyCountToImport = 0;
System.out.println(Counting keys to import, please wait...
(NOTE: to skip this use -n num_keys));
parser.nextToken(); // START_ARRAY
while (parser.nextToken() != null)
{
parser.skipChildren();
if (parser.getCurrentToken() == JsonToken.END_ARRAY)
break;
keyCountToImport++;
}
parser = getParser(jsonFile); // renewing parser only if we read
the file already - to support streaming.
}
--
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-5733) json2sstable can not read from a pipe even if -n and -s are specified.
Steven Lowenthal created CASSANDRA-5733:
---
Summary: json2sstable can not read from a pipe even if -n and -s
are specified.
Key: CASSANDRA-5733
URL: https://issues.apache.org/jira/browse/CASSANDRA-5733
Project: Cassandra
Issue Type: Improvement
Components: Tools
Affects Versions: 1.2.6
Reporter: Steven Lowenthal
Priority: Minor
SSTableImport.importSorted always opens the file twice even if the number of
keys are specifed. I changed this to only open the file a second time when -n
is not specified.
I moved the second parser = getparser ... call inside the if (keyCountToImport
== null) block.
if (keyCountToImport == null)
{
keyCountToImport = 0;
System.out.println(Counting keys to import, please wait... (NOTE:
to skip this use -n num_keys));
parser.nextToken(); // START_ARRAY
while (parser.nextToken() != null)
{
parser.skipChildren();
if (parser.getCurrentToken() == JsonToken.END_ARRAY)
break;
keyCountToImport++;
}
parser = getParser(jsonFile); // renewing parser only if we read the
file already - to support streaming.
}
--
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-5563) The CQL3 binary protocol does not allow a user to bind an empty buffer to signify the start of the token range
Steven Lowenthal created CASSANDRA-5563:
---
Summary: The CQL3 binary protocol does not allow a user to bind an
empty buffer to signify the start of the token range
Key: CASSANDRA-5563
URL: https://issues.apache.org/jira/browse/CASSANDRA-5563
Project: Cassandra
Issue Type: Improvement
Components: API
Affects Versions: 1.2.3
Reporter: Steven Lowenthal
Using CQL2 or CQL3 over thrift, one can issue a query which starts at the
beginning of the table by binding an empty buffer. The same is true for CQL2
using calls like get_range_slice. This is not allowed with the binary
protocol. Here is working sample code for CQL3 over thrift:
// Bind empty buffer to get query to start at the beginning of
// the table
ByteBuffer b = ByteBuffer.wrap(new byte[0]);
bindVars.add(b);
int cnt = 0;
CqlResult result;
do {
result = _client.execute_prepared_cql3_query(stmt.itemId, bindVars,
ConsistencyLevel.ONE);
// Set up the next chunk, by setting the bind var to the last received key
bindVars.set(0, ByteBuffer.wrap(result.getRows()
.get(result.getRows().size() -
1).getColumns().get(0).getValue()));
// Count rows
cnt += result.getRows().size();
if (cnt 100)
Assert.fail(Running past the end of the table: cnt = + cnt + ,
size() = + result.getRows().size());
} while (result.getRows().size() = CHUNK_SIZE);
Assert.assertEquals(Wrong count, 100, cnt);
}
--
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-5563) The CQL3 binary protocol does not allow a user to bind an empty buffer to signify the start of the token range
[
https://issues.apache.org/jira/browse/CASSANDRA-5563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Lowenthal updated CASSANDRA-5563:
Description:
Using CQL2 or CQL3 over thrift, one can issue a query which starts at the
beginning of the table by binding an empty buffer. The same is true for CQL2
using calls like get_range_slice. This is not allowed with the binary
protocol. Here is working sample code for CQL3 over thrift:
{code}
CqlPreparedResult stmt = _client.prepare_cql3_query(ByteBuffer.wrap(SELECT
\ Sequence number\ from \nhanes52simple\ where TOKEN (\ Sequence number\)
TOKEN(?) limit 15.getBytes()), Compression.NONE);
// Bind empty buffer to get query to start at the beginning of
// the table
ByteBuffer b = ByteBuffer.wrap(new byte[0]);
bindVars.add(b);
int cnt = 0;
CqlResult result;
do {
result = _client.execute_prepared_cql3_query(stmt.itemId, bindVars,
ConsistencyLevel.ONE);
// Set up the next chunk, by setting the bind var to the last received key
bindVars.set(0, ByteBuffer.wrap(result.getRows()
.get(result.getRows().size() -
1).getColumns().get(0).getValue()));
// Count rows
cnt += result.getRows().size();
if (cnt 100)
Assert.fail(Running past the end of the table: cnt = + cnt + ,
size() = + result.getRows().size());
} while (result.getRows().size() = CHUNK_SIZE);
Assert.assertEquals(Wrong count, 100, cnt);
}
{code}
was:
Using CQL2 or CQL3 over thrift, one can issue a query which starts at the
beginning of the table by binding an empty buffer. The same is true for CQL2
using calls like get_range_slice. This is not allowed with the binary
protocol. Here is working sample code for CQL3 over thrift:
{code}
// Bind empty buffer to get query to start at the beginning of
// the table
ByteBuffer b = ByteBuffer.wrap(new byte[0]);
bindVars.add(b);
int cnt = 0;
CqlResult result;
do {
result = _client.execute_prepared_cql3_query(stmt.itemId, bindVars,
ConsistencyLevel.ONE);
// Set up the next chunk, by setting the bind var to the last received key
bindVars.set(0, ByteBuffer.wrap(result.getRows()
.get(result.getRows().size() -
1).getColumns().get(0).getValue()));
// Count rows
cnt += result.getRows().size();
if (cnt 100)
Assert.fail(Running past the end of the table: cnt = + cnt + ,
size() = + result.getRows().size());
} while (result.getRows().size() = CHUNK_SIZE);
Assert.assertEquals(Wrong count, 100, cnt);
}
{code}
The CQL3 binary protocol does not allow a user to bind an empty buffer to
signify the start of the token range
--
Key: CASSANDRA-5563
URL: https://issues.apache.org/jira/browse/CASSANDRA-5563
Project: Cassandra
Issue Type: Improvement
Components: API
Affects Versions: 1.2.0
Reporter: Steven Lowenthal
Priority: Minor
Fix For: 1.2.5
Using CQL2 or CQL3 over thrift, one can issue a query which starts at the
beginning of the table by binding an empty buffer. The same is true for CQL2
using calls like get_range_slice. This is not allowed with the binary
protocol. Here is working sample code for CQL3 over thrift:
{code}
CqlPreparedResult stmt =
_client.prepare_cql3_query(ByteBuffer.wrap(SELECT \ Sequence number\ from
\nhanes52simple\ where TOKEN (\ Sequence number\) TOKEN(?) limit
15.getBytes()), Compression.NONE);
// Bind empty buffer to get query to start at the beginning of
// the table
ByteBuffer b = ByteBuffer.wrap(new byte[0]);
bindVars.add(b);
int cnt = 0;
CqlResult result;
do {
result = _client.execute_prepared_cql3_query(stmt.itemId, bindVars,
ConsistencyLevel.ONE);
// Set up the next chunk, by setting the bind var to the last received
key
bindVars.set(0, ByteBuffer.wrap(result.getRows()
.get(result.getRows().size() -
1).getColumns().get(0).getValue()));
// Count rows
cnt += result.getRows().size();
if (cnt 100)
Assert.fail(Running past the end of the table: cnt = + cnt + ,
size() = + result.getRows().size());
} while (result.getRows().size() = CHUNK_SIZE);
Assert.assertEquals(Wrong count, 100, cnt);
}
{code}
--
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-5563) The CQL3 binary protocol does not allow a user to bind an empty buffer to signify the start of the token range
[
https://issues.apache.org/jira/browse/CASSANDRA-5563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13656282#comment-13656282
]
Steven Lowenthal commented on CASSANDRA-5563:
-
Code amended. It does use token()
The CQL3 binary protocol does not allow a user to bind an empty buffer to
signify the start of the token range
--
Key: CASSANDRA-5563
URL: https://issues.apache.org/jira/browse/CASSANDRA-5563
Project: Cassandra
Issue Type: Improvement
Components: API
Affects Versions: 1.2.0
Reporter: Steven Lowenthal
Priority: Minor
Fix For: 1.2.5
Using CQL2 or CQL3 over thrift, one can issue a query which starts at the
beginning of the table by binding an empty buffer. The same is true for CQL2
using calls like get_range_slice. This is not allowed with the binary
protocol. Here is working sample code for CQL3 over thrift:
{code}
CqlPreparedResult stmt =
_client.prepare_cql3_query(ByteBuffer.wrap(SELECT \ Sequence number\ from
\nhanes52simple\ where TOKEN (\ Sequence number\) TOKEN(?) limit
15.getBytes()), Compression.NONE);
// Bind empty buffer to get query to start at the beginning of
// the table
ByteBuffer b = ByteBuffer.wrap(new byte[0]);
bindVars.add(b);
int cnt = 0;
CqlResult result;
do {
result = _client.execute_prepared_cql3_query(stmt.itemId, bindVars,
ConsistencyLevel.ONE);
// Set up the next chunk, by setting the bind var to the last received
key
bindVars.set(0, ByteBuffer.wrap(result.getRows()
.get(result.getRows().size() -
1).getColumns().get(0).getValue()));
// Count rows
cnt += result.getRows().size();
if (cnt 100)
Assert.fail(Running past the end of the table: cnt = + cnt + ,
size() = + result.getRows().size());
} while (result.getRows().size() = CHUNK_SIZE);
Assert.assertEquals(Wrong count, 100, cnt);
}
{code}
--
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-5369) cqlsh drops characters from script files with wrong version of the Python libedit (readline) library
Steven Lowenthal created CASSANDRA-5369: --- Summary: cqlsh drops characters from script files with wrong version of the Python libedit (readline) library Key: CASSANDRA-5369 URL: https://issues.apache.org/jira/browse/CASSANDRA-5369 Project: Cassandra Issue Type: Bug Affects Versions: 2.1 Environment: MAC OSX Python 2.7.3. readline (unknown version) Reporter: Steven Lowenthal If an python installation has the wrong version of readline, cqlsh does not allow non-ascii characters such as in the word café. When reading a script, cqlsh simply drops those characters out of the script. In my case, the script contained insert statements, and C* thereby inserted bad data. cqlsh needs to throw if there is a version of readline that exhibits this behavior. This behavior was exhibited in my version of OSX 10.8 It was remedied by upgrading readline: Steves-MacBook-Pro:bin stevelowenthal$ sudo easy_install readline Password: Searching for readline Reading http://pypi.python.org/simple/readline/ Reading http://github.com/ludwigschwardt/python-readline Reading http://www.python.org/ Best match: readline 6.2.4.1 Downloading http://pypi.python.org/packages/2.7/r/readline/readline-6.2.4.1-py2.7-macosx-10.7-intel.egg#md5=6ede61046a61219a6d97c44a75853c23 Processing readline-6.2.4.1-py2.7-macosx-10.7-intel.egg creating /Library/Python/2.7/site-packages/readline-6.2.4.1-py2.7-macosx-10.7-intel.egg Extracting readline-6.2.4.1-py2.7-macosx-10.7-intel.egg to /Library/Python/2.7/site-packages Adding readline 6.2.4.1 to easy-install.pth file Installed /Library/Python/2.7/site-packages/readline-6.2.4.1-py2.7-macosx-10.7-intel.egg Processing dependencies for readline -- 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-5336) C* crashes with an OOM error when using the Simba Driver on a very wide table
[ https://issues.apache.org/jira/browse/CASSANDRA-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602761#comment-13602761 ] Steven Lowenthal commented on CASSANDRA-5336: - I'll work with Simba on this as get_count look like a much better API. C* crashes with an OOM error when using the Simba Driver on a very wide table - Key: CASSANDRA-5336 URL: https://issues.apache.org/jira/browse/CASSANDRA-5336 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.1.6 Environment: C* on a Mac with 1GB VM. Simba ODBC driver Reporter: Steven Lowenthal Attachments: nhanes600-10k.tarZ, thrift.in, thrift.out The Simba driver executes a version of a count(*) query: SELECT SUM(1) from nhanes3 having sum(1) 0. It uses this format so ODBC returns a no rows found error if the table is empty. It translates into a series of get_range_slice calls which bring back all of the rows, and for every row, it brings back every single column name. C* crashes with an OOM in the thrift code. The table has almost 600 columns of mixed text and numeric data with many empty values. -- 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-5336) C* crashes with an OOM error when using the Simba Driver on a very wide table
[ https://issues.apache.org/jira/browse/CASSANDRA-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602799#comment-13602799 ] Steven Lowenthal commented on CASSANDRA-5336: - Doesn't get_count count columns, and not rows? C* crashes with an OOM error when using the Simba Driver on a very wide table - Key: CASSANDRA-5336 URL: https://issues.apache.org/jira/browse/CASSANDRA-5336 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.1.6 Environment: C* on a Mac with 1GB VM. Simba ODBC driver Reporter: Steven Lowenthal Attachments: nhanes600-10k.tarZ, thrift.in, thrift.out The Simba driver executes a version of a count(*) query: SELECT SUM(1) from nhanes3 having sum(1) 0. It uses this format so ODBC returns a no rows found error if the table is empty. It translates into a series of get_range_slice calls which bring back all of the rows, and for every row, it brings back every single column name. C* crashes with an OOM in the thrift code. The table has almost 600 columns of mixed text and numeric data with many empty values. -- 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-5336) C* crashes with an OOM error when using the Simba Driver on a very wide table
Steven Lowenthal created CASSANDRA-5336: --- Summary: C* crashes with an OOM error when using the Simba Driver on a very wide table Key: CASSANDRA-5336 URL: https://issues.apache.org/jira/browse/CASSANDRA-5336 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.1.6 Environment: C* on a Mac with 1GB VM. Simba ODBC driver Reporter: Steven Lowenthal The Simba driver executes a version of a count(*) query: SELECT SUM(1) from nhanes3 having sum(1) 0. It uses this format so ODBC returns a no rows found error if the table is empty. It translates into a series of get_range_slice calls which bring back all of the rows, and for every row, it brings back every single column name. C* crashes with an OOM in the thrift code. The table has almost 600 columns of mixed text and numeric data with many empty values. -- 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-5336) C* crashes with an OOM error when using the Simba Driver on a very wide table
[ https://issues.apache.org/jira/browse/CASSANDRA-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Lowenthal updated CASSANDRA-5336: Attachment: nhanes600-10k.tarZ 10K rows is sufficient to reproduce. C* crashes with an OOM error when using the Simba Driver on a very wide table - Key: CASSANDRA-5336 URL: https://issues.apache.org/jira/browse/CASSANDRA-5336 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.1.6 Environment: C* on a Mac with 1GB VM. Simba ODBC driver Reporter: Steven Lowenthal Attachments: nhanes600-10k.tarZ The Simba driver executes a version of a count(*) query: SELECT SUM(1) from nhanes3 having sum(1) 0. It uses this format so ODBC returns a no rows found error if the table is empty. It translates into a series of get_range_slice calls which bring back all of the rows, and for every row, it brings back every single column name. C* crashes with an OOM in the thrift code. The table has almost 600 columns of mixed text and numeric data with many empty values. -- 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-5336) C* crashes with an OOM error when using the Simba Driver on a very wide table
[ https://issues.apache.org/jira/browse/CASSANDRA-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Lowenthal updated CASSANDRA-5336: Attachment: thrift.out thrift.in C* crashes with an OOM error when using the Simba Driver on a very wide table - Key: CASSANDRA-5336 URL: https://issues.apache.org/jira/browse/CASSANDRA-5336 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.1.6 Environment: C* on a Mac with 1GB VM. Simba ODBC driver Reporter: Steven Lowenthal Attachments: nhanes600-10k.tarZ, thrift.in, thrift.out The Simba driver executes a version of a count(*) query: SELECT SUM(1) from nhanes3 having sum(1) 0. It uses this format so ODBC returns a no rows found error if the table is empty. It translates into a series of get_range_slice calls which bring back all of the rows, and for every row, it brings back every single column name. C* crashes with an OOM in the thrift code. The table has almost 600 columns of mixed text and numeric data with many empty values. -- 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-5336) C* crashes with an OOM error when using the Simba Driver on a very wide table
[ https://issues.apache.org/jira/browse/CASSANDRA-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13600600#comment-13600600 ] Steven Lowenthal commented on CASSANDRA-5336: - I think a simple select count(*) from table limit 1; will do it. The trace was produced with a simpler tool nettool. It's very handy. That begs the question of building a thrift trace / playback tool. It may be helpful for support and load testing. C* crashes with an OOM error when using the Simba Driver on a very wide table - Key: CASSANDRA-5336 URL: https://issues.apache.org/jira/browse/CASSANDRA-5336 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.1.6 Environment: C* on a Mac with 1GB VM. Simba ODBC driver Reporter: Steven Lowenthal Attachments: nhanes600-10k.tarZ, thrift.in, thrift.out The Simba driver executes a version of a count(*) query: SELECT SUM(1) from nhanes3 having sum(1) 0. It uses this format so ODBC returns a no rows found error if the table is empty. It translates into a series of get_range_slice calls which bring back all of the rows, and for every row, it brings back every single column name. C* crashes with an OOM in the thrift code. The table has almost 600 columns of mixed text and numeric data with many empty values. -- 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
