[
https://issues.apache.org/jira/browse/CASSANDRA-4657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13470899#comment-13470899
]
Jonathan Ellis commented on CASSANDRA-4657:
-------------------------------------------
Thanks Emmanuel!
Your patch will work, but I'd like to do a deeper cleanup.
I've pushed this to https://github.com/jbellis/cassandra/branches/4657.
In order these commits
# fix cql version reset under the existing regime of
CassandraServer.clientState threadlocal
# centralizes all session management into ThriftSessionManager
# removes the threadlocal approach in favor of standardizing on the
socket-based approach everywhere
> cql version race condition with rpc_server_type: sync
> -----------------------------------------------------
>
> Key: CASSANDRA-4657
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4657
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1.0
> Environment: Ubuntu 12.04
> Reporter: Emmanuel Courreges
> Labels: features
> Fix For: 1.1.6
>
> Attachments: 4657.patch
>
>
> If clients connect to a cassandra cluster configured with rpc_server_type:
> sync with heterogeneous cql versions (2 and 3), the cql version used for
> execution on the server changes seemingly randomly.
> It's due to the fact that CustomTThreadPoolServer.java does not set the
> remoteSocket anytime, or does not clear the cql version in the ThreadLocal
> clientState object.
> When CassandraServer.java calls state() it gets the ThreadLocal object
> clientState, which has its cqlversion already changed by a previous socket
> that was using the same thread.
> The easiest fix is probably to do a
> SocketSessionManagementService.instance.set when accepting a new client and
> SocketSessionManagementService.instance.remove when the client is closed, but
> if you really want to use the ThreadLocal clientState and not alloc/destroy a
> ClientState everytime, then you should clear this clientState on accept of a
> new client.
> The problem can be reproduced with cqlsh -3 on one side and a client that
> does not set the cql version, expecting to get version 2 by default, but
> actually gettingv v2/v3 depending on which thread it connects to.
> The problem does not happen with other rpc_server_types, nor with clients
> that set their cql version at connection.
--
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
