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 >
