Re: lightweight transactions with potential problem?
By the way, I do not understand why in lightweight transactions in Cassandra has round-trip commit/acknowledgment? For me, I think we can commit the value within phase propose/accept. Do you agree? If not agree can you explain why we need commit/acknowledgment? No, value cannot be committed during the propose/accept phase, because nothing should be committed *before* the coordinator of the round has received a QUORUM of accepts. In other words, you have to wait on the result of the propose/accept to know if you can commit or not. This is not at all specific to Cassandra btw: you'll find this in most Paxos presentation, generally named as the learning phase. -- Sylvain
Re: 'no such object in table'
LOCAL_JMX=no if [ $LOCAL_JMX = yes ]; then JVM_OPTS=$JVM_OPTS -Dcassandra.jmx.local.port=$JMX_PORT -XX:+DisableExplicitGC else JVM_OPTS=$JVM_OPTS -Dcom.sun.management.jmxremote.port=$JMX_PORT JVM_OPTS=$JVM_OPTS -Dcom.sun.management.jmxremote.rmi.port=$JMX_PORT JVM_OPTS=$JVM_OPTS -Dcom.sun.management.jmxremote.ssl=false JVM_OPTS=$JVM_OPTS -Dcom.sun.management.jmxremote.authenticate=false JVM_OPTS=$JVM_OPTS -Dcom.sun.management.jmxremote.password.file=/etc/cassandra/jmxremote.password fi Retry with the following option added to your JVM_OPTS: java.rmi.server.logCalls=true This should produce some more information about what is going on. -- - Nate McCall Austin, TX @zznate Co-Founder Sr. Technical Consultant Apache Cassandra Consulting http://www.thelastpickle.com
RE: PrepareStatement BUG
See https://issues.apache.org/jira/browse/CASSANDRA-7910 From: joseph gao [mailto:gaojf.bok...@gmail.com] Sent: Wednesday, August 26, 2015 6:15 AM To: user@cassandra.apache.org Subject: Re: PrepareStatement BUG Hi, anybody knows how to resolve this problem? 2015-08-23 1:35 GMT+08:00 joseph gao gaojf.bok...@gmail.commailto:gaojf.bok...@gmail.com: I'm using cassandra 2.1.7 and datastax java drive 2.1.6 Here is the problem: I use PrepareStatement for query like : SELECT * FROM somespace.sometable where id = ? And I Cached the PrepareStatement in my jvm; When the table metadata has changed like a column was added; And I use the cached PrepareStament , the data and the metadata(column definations) don't match. So I re-prepare the sql using session.prepare(sql) again, but i see the code in the async-prepare callback part: stmt = cluster.manager.addPrepare(stmt); in the SessionManager.java this will return the previous PrepareStatement. So it neither re-prepare automatically nor allow user to re-prepare! Is this a bug or I use it like a fool? -- -- Joseph Gao PhoneNum:15210513582 QQ: 409343351 -- -- Joseph Gao PhoneNum:15210513582 QQ: 409343351
How to get the peer's IP address when writing failed
Hi, All, We have an Cassandra environment with two connected DCs and our consistency level of writing operation is EACH_QUORUM. So if one DC is down, the write will be failed and we get TokenRangeOfflineException on the client side (we use netfilix java client libraries). We want to give more detailed information about this failure. e.g. The IP addresses of the broken nodes (on the broken DC in our case). We checked the TokenRangeOfflineException and its parent class ConnectionException. The only related method is getHost(). But it returns the IP address of the local node (the node that issues the writing operation) instead of the remote node on the broken DC. Does anyone know how to get such information when writing failed? Thanks Boying
Re: lightweight transactions with potential problem?
Yes, Sylvain, your answer makes more sense. The phase is in Paxos protocol sometimes called learning or decide phase, BUT this phase does not have acknowledgment round, just learning or decide message from the proposer to learners. So why we need acknowledgment round with commit phase in lightweight transactions?
Re: lightweight transactions with potential problem?
On Wed, Aug 26, 2015 at 12:19 PM, ibrahim El-sanosi ibrahimsaba...@gmail.com wrote: Yes, Sylvain, your answer makes more sense. The phase is in Paxos protocol sometimes called learning or decide phase, BUT this phase does not have acknowledgment round, just learning or decide message from the proposer to learners. So why we need acknowledgment round with commit phase in lightweight transactions? It's not _needed_ as far as Paxos is concerned. But it's useful in the context of Cassandra. The commit phase is about actually persisting to replica the update decided by the Paxos algorithm and thus making that update visible to non paxos reads. Being able to apply normal consistencies to this phase is thus useful, since it allows user to get visibility guarantees even for non-paxos reads if they so wish, and that's exactly what we do and why we optionally wait on acknowledgments (and I say optionally because how many acks we wait on depends on the user provided consistency level and if that's CL.ANY then the whole Paxos operation actually return without waiting on any of those acks).
Re: lightweight transactions with potential problem?
Thank you lot Ibrahim On Wed, Aug 26, 2015 at 12:15 PM, Sylvain Lebresne sylv...@datastax.com wrote: Yes On Wed, Aug 26, 2015 at 1:05 PM, ibrahim El-sanosi ibrahimsaba...@gmail.com wrote: OK. I see what the purpose of acknowledgment round here. So acknowledgment is optional here, depend on CL setting as we normally do in Cassandra. So we can say that acknowledgment is not really related to Paxos phase, it depends on CL in Cassandra? Ibrahim On Wed, Aug 26, 2015 at 11:50 AM, Sylvain Lebresne sylv...@datastax.com wrote: On Wed, Aug 26, 2015 at 12:19 PM, ibrahim El-sanosi ibrahimsaba...@gmail.com wrote: Yes, Sylvain, your answer makes more sense. The phase is in Paxos protocol sometimes called learning or decide phase, BUT this phase does not have acknowledgment round, just learning or decide message from the proposer to learners. So why we need acknowledgment round with commit phase in lightweight transactions? It's not _needed_ as far as Paxos is concerned. But it's useful in the context of Cassandra. The commit phase is about actually persisting to replica the update decided by the Paxos algorithm and thus making that update visible to non paxos reads. Being able to apply normal consistencies to this phase is thus useful, since it allows user to get visibility guarantees even for non-paxos reads if they so wish, and that's exactly what we do and why we optionally wait on acknowledgments (and I say optionally because how many acks we wait on depends on the user provided consistency level and if that's CL.ANY then the whole Paxos operation actually return without waiting on any of those acks).
Re: lightweight transactions with potential problem?
Yes On Wed, Aug 26, 2015 at 1:05 PM, ibrahim El-sanosi ibrahimsaba...@gmail.com wrote: OK. I see what the purpose of acknowledgment round here. So acknowledgment is optional here, depend on CL setting as we normally do in Cassandra. So we can say that acknowledgment is not really related to Paxos phase, it depends on CL in Cassandra? Ibrahim On Wed, Aug 26, 2015 at 11:50 AM, Sylvain Lebresne sylv...@datastax.com wrote: On Wed, Aug 26, 2015 at 12:19 PM, ibrahim El-sanosi ibrahimsaba...@gmail.com wrote: Yes, Sylvain, your answer makes more sense. The phase is in Paxos protocol sometimes called learning or decide phase, BUT this phase does not have acknowledgment round, just learning or decide message from the proposer to learners. So why we need acknowledgment round with commit phase in lightweight transactions? It's not _needed_ as far as Paxos is concerned. But it's useful in the context of Cassandra. The commit phase is about actually persisting to replica the update decided by the Paxos algorithm and thus making that update visible to non paxos reads. Being able to apply normal consistencies to this phase is thus useful, since it allows user to get visibility guarantees even for non-paxos reads if they so wish, and that's exactly what we do and why we optionally wait on acknowledgments (and I say optionally because how many acks we wait on depends on the user provided consistency level and if that's CL.ANY then the whole Paxos operation actually return without waiting on any of those acks).
Re: lightweight transactions with potential problem?
OK. I see what the purpose of acknowledgment round here. So acknowledgment is optional here, depend on CL setting as we normally do in Cassandra. So we can say that acknowledgment is not really related to Paxos phase, it depends on CL in Cassandra? Ibrahim On Wed, Aug 26, 2015 at 11:50 AM, Sylvain Lebresne sylv...@datastax.com wrote: On Wed, Aug 26, 2015 at 12:19 PM, ibrahim El-sanosi ibrahimsaba...@gmail.com wrote: Yes, Sylvain, your answer makes more sense. The phase is in Paxos protocol sometimes called learning or decide phase, BUT this phase does not have acknowledgment round, just learning or decide message from the proposer to learners. So why we need acknowledgment round with commit phase in lightweight transactions? It's not _needed_ as far as Paxos is concerned. But it's useful in the context of Cassandra. The commit phase is about actually persisting to replica the update decided by the Paxos algorithm and thus making that update visible to non paxos reads. Being able to apply normal consistencies to this phase is thus useful, since it allows user to get visibility guarantees even for non-paxos reads if they so wish, and that's exactly what we do and why we optionally wait on acknowledgments (and I say optionally because how many acks we wait on depends on the user provided consistency level and if that's CL.ANY then the whole Paxos operation actually return without waiting on any of those acks).
Re: 'no such object in table'
All of my nodes have the same cassandra-env.sh. Only a few of them complain. LOCAL_JMX=no if [ $LOCAL_JMX = yes ]; then JVM_OPTS=$JVM_OPTS -Dcassandra.jmx.local.port=$JMX_PORT -XX:+DisableExplicitGC else JVM_OPTS=$JVM_OPTS -Dcom.sun.management.jmxremote.port=$JMX_PORT JVM_OPTS=$JVM_OPTS -Dcom.sun.management.jmxremote.rmi.port=$JMX_PORT JVM_OPTS=$JVM_OPTS -Dcom.sun.management.jmxremote.ssl=false JVM_OPTS=$JVM_OPTS -Dcom.sun.management.jmxremote.authenticate=false JVM_OPTS=$JVM_OPTS -Dcom.sun.management.jmxremote.password.file=/etc/cassandra/jmxremote.password fi On Tue, Aug 25, 2015 at 4:35 PM, Michael Shuler mich...@pbandjelly.org wrote: On 08/25/2015 02:19 PM, Jason Lewis wrote: I'm trying to run nodetool from one node, connecting to another. I can successfully connect to the majority of nodes in my ring, but two nodes throw the following error. nodetool: Failed to connect to 'IP:7199' NoSuchObjectException: 'no such object in table'. Any idea why this is happening? Misconfiguration? Possibly. Check those nodes to see if 7199 is listening to only localhost or some private IP your client node cannot reach (failed to connect). The default is to only listen on localhost, as seen on my machine: $ netstat -ln | grep 7199 tcp0 0 127.0.0.1:7199 0.0.0.0:* LISTEN JMX configuration is set in conf/cassandra-env.sh - please, configure JMX security as documented in that file and/or firewall JMX. Check all your nodes JMX security configs! :) -- Kind regards, Michael
