[
https://issues.apache.org/jira/browse/CASSANDRA-4657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Courreges updated CASSANDRA-4657:
------------------------------------------
Description:
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.
was:
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.put
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.
> 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.1, 1.1.2, 1.1.5
> Environment: Ubuntu 12.04
> Reporter: Emmanuel Courreges
> Labels: features
>
> 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
