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
