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 <beggles...@apple.com.INVALID> > wrote: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
