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 <jeremiah.jor...@gmail.com> wrote: > > It is inherently versioned by the protocol version being used for the > connection. > >> On Sep 24, 2019, at 9:06 PM, Jon Haddad <j...@jonhaddad.com> 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 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 separately versioning the paging state. >> >> I think recognizing max int as special number that just means "a lot" is >> fine for now till we have time to rework it is a reasonable approach. >> >> Jon >> >>> On Tue, Sep 24, 2019 at 6:52 PM J. D. Jordan <jeremiah.jor...@gmail.com> >>> wrote: >>> >>> 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 >>> opaque, but that doesn’t mean a driver would send the new payload to an old >>> server. >>> >>> Many of the drivers I have looked at don’t do mixed version connections. >>> If they start at a higher version they will not connect to older nodes that >>> don’t support it. Or they will connect to the newer nodes with the older >>> protocol version. In either of those cases there is no problem. >>> >>> Protocol changes aside, I would suggest fixing the bug starting back on >>> 3.x by changing the meaning of MAX. Whether or not the limit is switched to >>> a var int in a bumped protocol version. >>> >>> -Jeremiah >>> >>> >>>> On Sep 24, 2019, at 8:28 PM, Blake Eggleston >>> <beggles...@apple.com.invalid> wrote: >>>> >>>> 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 <jerem...@datastax.com> >>> wrote: >>>>> >>>>> 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 back to 3.x and >>> fix the bug in all versions, letting users requests to receive all of their >>> data. Which realistically is probably what someone who sets the protocol >>> level query limit to Integer.MAX_VALUE is trying to do. >>>>> >>>>> -Jeremiah >>>>> >>>>>>> On Sep 24, 2019, at 4:09 PM, Blake Eggleston >>> <beggles...@apple.com.invalid> wrote: >>>>>> >>>>>> 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 protocol version where the paging state serialization format has >>> changed. This causes an exception deserializing the paging state and the >>> read fails. >>>>>> >>>>>> There are ways around this, but they're not comprehensive (I think), >>> and they're much more involved than just interpreting Integer.MAX_VALUE as >>> unlimited. The "right" solution would be for the paging state to be >>> deserialized/serialized on the client side, but that won't happen in 4.0. >>>>>> >>>>>>>> On Sep 24, 2019, at 1:12 PM, Jon Haddad <j...@jonhaddad.com> wrote: >>>>>>>> >>>>>>>> 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 >>>>>>>> <beggles...@apple.com.invalid> 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 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 <j...@jonhaddad.com> wrote: >>>>>>>>> >>>>>>>>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_CASSANDRA-2D14683&d=DwIFAg&c=adz96Xi0w1RHqtPMowiL2g&r=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g&m=6_gWDV_kv-TQJ8GyBlYfcrhPGl7WmGYGEJ9ET6rPARo&s=LcYkbQwf4gzl8tnMcVbFKr3PeZ_u8mHHnXTBRWtIZFU&e= >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
