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
