Re: fixing paging state for 4.0
And as I said, that would be a bug in the driver that did this. Any driver implementing a protocol that has a “new” paging state, that supports mixed version connections, would need to handle that correctly and not send new states over the old protocol or old states over the new protocol. As far as I know the current java driver does not support mixed protocol versions across its connections. So it would not need such logic. But and driver that supported mixed versions would need it. > On Sep 24, 2019, at 9:20 PM, Blake Eggleston > 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. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: fixing paging state for 4.0
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 > 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 wrote: >> >> It is inherently versioned by the protocol version being used for the >> connection. >> >>> On Sep 24, 2019, at 9:06 PM, Jon Haddad 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 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 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 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 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 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 > 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 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. >>
Re: fixing paging state for 4.0
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 wrote: > > It is inherently versioned by the protocol version being used for the > connection. > >> On Sep 24, 2019, at 9:06 PM, Jon Haddad 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 >>> 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 >>> 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 >>> 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 >>> 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 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 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 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=DwIFAg=adz96Xi0w1RHqtPMowiL2g=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g=6_gWDV_kv-TQJ8GyBlYfcrhPGl7WmGYGEJ9ET6rPARo=LcYkbQwf4gzl8tnMcVbFKr3PeZ_u8mHHnXTBRWtIZFU=
Re: fixing paging state for 4.0
It is inherently versioned by the protocol version being used for the connection. > On Sep 24, 2019, at 9:06 PM, Jon Haddad 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 >> 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 >> 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 >> 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 >> 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 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 >>> 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 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=DwIFAg=adz96Xi0w1RHqtPMowiL2g=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g=6_gWDV_kv-TQJ8GyBlYfcrhPGl7WmGYGEJ9ET6rPARo=LcYkbQwf4gzl8tnMcVbFKr3PeZ_u8mHHnXTBRWtIZFU= >>> >>> >>> - >>> 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:
Re: fixing paging state for 4.0
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 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 > 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 > 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 > 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 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 > > 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 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=DwIFAg=adz96Xi0w1RHqtPMowiL2g=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g=6_gWDV_kv-TQJ8GyBlYfcrhPGl7WmGYGEJ9ET6rPARo=LcYkbQwf4gzl8tnMcVbFKr3PeZ_u8mHHnXTBRWtIZFU= > > > > > > - > > 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 >
Re: fixing paging state for 4.0
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 > 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 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 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 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 > 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 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=DwIFAg=adz96Xi0w1RHqtPMowiL2g=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g=6_gWDV_kv-TQJ8GyBlYfcrhPGl7WmGYGEJ9ET6rPARo=LcYkbQwf4gzl8tnMcVbFKr3PeZ_u8mHHnXTBRWtIZFU= >> > > > - > 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
Re: fixing paging state for 4.0
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 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 >> 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 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 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 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=DwIFAg=adz96Xi0w1RHqtPMowiL2g=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g=6_gWDV_kv-TQJ8GyBlYfcrhPGl7WmGYGEJ9ET6rPARo=LcYkbQwf4gzl8tnMcVbFKr3PeZ_u8mHHnXTBRWtIZFU= > - 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
Re: fixing paging state for 4.0
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 > 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 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 >>> 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 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=DwIFAg=adz96Xi0w1RHqtPMowiL2g=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g=6_gWDV_kv-TQJ8GyBlYfcrhPGl7WmGYGEJ9ET6rPARo=LcYkbQwf4gzl8tnMcVbFKr3PeZ_u8mHHnXTBRWtIZFU= >>> >>> >>> - >>> 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 >
Re: fixing paging state for 4.0
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 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 > 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 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://issues.apache.org/jira/browse/CASSANDRA-14683 >> >> >> - >> 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
Re: fixing paging state for 4.0
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 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 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://issues.apache.org/jira/browse/CASSANDRA-14683 > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: fixing paging state for 4.0
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 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://issues.apache.org/jira/browse/CASSANDRA-14683 - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
fixing paging state for 4.0
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://issues.apache.org/jira/browse/CASSANDRA-14683
