Wrong data returned due to reusing stream ids of requests that timed out on the client side
Description
Context: The driver allows to send multiple requests concurrently using a single connection. Requests are matched with the corresponding responses using stream ids. Each request gets a unique stream id and the corresponding response contains the same stream id. The pool of stream ids is limited and in CQL protocol v3 and above has 32768 values. That means stream ids have to be reused. Usually when the request gets a response, the stream id used by this request is returned to the pool.
Problem: The driver has an ability to time out a request on a client side. The problem is that when such situation happens, the stream id of the timed out request is returned to the pool of available stream ids and another request can pick up the same stream id.
Problematic situation looks as follows: 1. request R1 is sent to the server with stream id S 2. request R1 times out due to a client-side time out 3. stream id S is returned to the pool of available streams 4. request R2 is sent to the server with stream id S 5. Server sends back a response to the request R1. Such response contains stream id S and is now interpreted as a response to the request R2.
This leads to data being returned for one query being interpreted as a response to another query. For example if user sessions are stored in the DB under a user_id primary key then one user could get session of another.
Context:
The driver allows to send multiple requests concurrently using a single connection.
Requests are matched with the corresponding responses using stream ids.
Each request gets a unique stream id and the corresponding response contains the same stream id.
The pool of stream ids is limited and in CQL protocol v3 and above has 32768 values.
That means stream ids have to be reused.
Usually when the request gets a response, the stream id used by this request is returned to the pool.
Problem:
The driver has an ability to time out a request on a client side.
The problem is that when such situation happens, the stream id of the timed out request is returned to the pool of available stream ids and another request can pick up the same stream id.
Problematic situation looks as follows:
1. request R1 is sent to the server with stream id S
2. request R1 times out due to a client-side time out
3. stream id S is returned to the pool of available streams
4. request R2 is sent to the server with stream id S
5. Server sends back a response to the request R1. Such response contains stream id S and is now interpreted as a response to the request R2.
This leads to data being returned for one query being interpreted as a response to another query.
For example if user sessions are stored in the DB under a user_id primary key then one user could get session of another.