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
