And as I said, that would be a bug in the driver that did this. Any driver
implementing a protocol that has a “new” paging state, that supports mixed
version connections, would need to handle that correctly and not send new
states over the old protocol or old states over the new protocol.
As fa
Sorry, I misread your earlier email. Yes, there are drivers that do mixed
protocol versions. Not sure if the 4.0 java driver does, but at least one
previous version did.
> On Sep 24, 2019, at 7:19 PM, Blake Eggleston
> wrote:
>
> Yes, but if a client is connected to 2 different nodes, and is
Yes, but if a client is connected to 2 different nodes, and is using a
different protocol for each, the paging state formats aren’t going to match if
it tries to use the paging date from one connection on the other.
> On Sep 24, 2019, at 7:14 PM, J. D. Jordan wrote:
>
> It is inherently versi
It is inherently versioned by the protocol version being used for the
connection.
> On Sep 24, 2019, at 9:06 PM, Jon Haddad wrote:
>
> The problem is that the payload isn't versioned, because the individual
> fields aren't really part of the protocol. I think the long term fix
> should be to
The problem is that the payload isn't versioned, because the individual
fields aren't really part of the protocol. I think the long term fix
should be to add the fields of the paging state to the protocol itself
rather than have it just be some serialized blob. Then we don't have to
deal with sep
Are their drivers that try to do mixed protocol version connections? If so
that would be a mistake on the drivers part if it sent the new paging state to
an old server. Pretty easily protected against in said driver when it
implements support for the new protocol version. The payload is opaqu
Right, that's the problem with changing the paging state format. It doesn't
work in mixed mode.
> On Sep 24, 2019, at 4:47 PM, Jeremiah Jordan wrote:
>
> Clients do negotiate the protocol version they use when connecting. If the
> server bumped the protocol version then this larger paging stat
Clients do negotiate the protocol version they use when connecting. If the
server bumped the protocol version then this larger paging state could be part
of the new protocol version. But that doesn’t solve the problem for existing
versions.
The special treatment of Integer.MAX_VALUE can be done
Right, mixed version clusters. The opaque blob isn't versioned, and there isn't
an opportunity for min version negotiation that you have with the messaging
service. The result is situations where a client begins a read on one node, and
attempts to read the next page from a different node over a
What's the pain point? Is it because of mixed version clusters or is there
something else that makes it a problem?
On Tue, Sep 24, 2019 at 11:03 AM Blake Eggleston
wrote:
> Changing paging state format is kind of a pain since the driver treats it
> as an opaque blob. I'd prefer we went with Syl
Changing paging state format is kind of a pain since the driver treats it as an
opaque blob. I'd prefer we went with Sylvain's suggestion to just interpret
Integer.MAX_VALUE as "no limit", which would be a lot simpler to implement.
> On Sep 24, 2019, at 10:44 AM, Jon Haddad wrote:
>
> I'm work
I'm working with a team who just ran into CASSANDRA-14683 [1], which I
didn't realize was an issue till now.
Anyone have an interest in fixing full table pagination? I'm not sure of
the full implications of changing the int to a long in the paging stage.
https://issues.apache.org/jira/browse/CAS
12 matches
Mail list logo
