I've resolved this bug to be within my own php client wrapper and thus not in Cassandra (great to know :). The bug was that upon TException from get_slice the client code didn't correctly close the socket but instead kept using it. This resulted that the timeouted response was eventually delivered into the socket and thus next get_slice operation got this delayed data instead of the expected data.
I published my client libraries earlier in another message and I've also uploaded them into github: http://github.com/dynamoid/cassandra-utilities Thanks Benjamin for your input on the subject :) - Juho Mäkinen On Mon, Aug 30, 2010 at 11:15 PM, Juho Mäkinen <juho.maki...@gmail.com> wrote: > I'm not using connection poolin where the same tcp socket is used > between different php requests. I open a new thrift connection with > new socket to the node and I use the node through the request and I > close it after. The get_slice requests are all happening in the same > request, so something odd happens in the between. > > Tomorrow I'm going to implement a history buffer which logs all > cassandra operations within the php request and logs it out in case I > detect this anomaly again. Hopefully that gives some light to the > problem. > > - Juho Mäkinen > > On Mon, Aug 30, 2010 at 10:50 PM, Benjamin Black <b...@b3k.us> wrote: >> On Mon, Aug 30, 2010 at 6:05 AM, Juho Mäkinen <juho.maki...@gmail.com> wrote: >>> The application is using the >>> same cassandra thrift connection (it doesn't close it in between) and >>> everything is happening inside same php process. >>> >> >> This is why you are seeing this problem (and is specific to connection >> reuse in certain languages, not a general problem with connection >> reuse). >> >> >> b >> >
