Re: Protocol-impacting (internode and client) changes for 4.0
While the protocol's being changed, does it make sense to add in CASSANDRA-13292 as well? Or at least, some sort of ability to choose a hash algorithm? On Wed, Oct 9, 2019 at 1:32 PM Dinesh Joshi wrote: > +1 > > Dinesh > > > On Oct 9, 2019, at 12:41 PM, Joshua McKenzie > wrote: > > > >> > >> each one of them is extremely low risk, which means that any validation > >> effort that has already happened won't have to be re-done > > > > +1 > > > > On Wed, Oct 9, 2019 at 1:46 PM Jon Haddad wrote: > > > >> Seems reasonable, especially since we're in alpha mode. > >> > >> On Wed, Oct 9, 2019 at 10:28 AM Aleksey Yeshchenko > >> wrote: > >> > >>> +1; in particular since the protocol itself is still in beta > >>> > On 9 Oct 2019, at 17:26, Oleksandr Petrov > > >>> wrote: > > Hi, > > During NGCC/ACNA19 we've had quite a few conversations around the 4.0 > release. Many (minor) features and changes suggested during that time > >> are > possible to implement in 4.next without any problem. However, some > >>> changes > that seem to be very important for the community, which got mentioned > >> in > several conversations, are not possible to implement without protocol > changes. By *protocol* changes here I mean both native and client > >>> protocol. > > Here's a shortlist of the issues in question: > https://issues.apache.org/jira/browse/CASSANDRA-15349 Add “Going > away” > message to the client protocol > https://issues.apache.org/jira/browse/CASSANDRA-15350 Add CAS > >>> “uncertainty” > and “contention" messages that are currently propagated as a > WriteTimeoutException. > https://issues.apache.org/jira/browse/CASSANDRA-15351 Allow > >> configuring > timeouts on the per-request basis > https://issues.apache.org/jira/browse/CASSANDRA-15352 Replica failure > propagation to coordinator and client > https://issues.apache.org/jira/browse/CASSANDRA-15299 Improve > >>> checksumming > and compression in protocol v5-beta > > And, less importantly - CASSANDRA-14683 (paging state issue). > > My suggestion would be to lift a freeze for all (or at least some) of > >>> these > issues, since they seem to be quite important for operators and each > >> one > >>> of > them is extremely low risk, which means that any validation effort > that > >>> has > already happened won't have to be re-done. All of the issues are > fairly > easy to implement, which means they won't delay the release. > > To my best knowledge, there's no client that fully supports 4.0, I > >> think > doing this now actually makes sense, meaning that driver implementers > >>> won't > really have to redo anything. > > Your thoughts on this are welcome, > -- Alex > >>> > >>> > >>> - > >>> 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: Protocol-impacting (internode and client) changes for 4.0
+1 Dinesh > On Oct 9, 2019, at 12:41 PM, Joshua McKenzie wrote: > >> >> each one of them is extremely low risk, which means that any validation >> effort that has already happened won't have to be re-done > > +1 > > On Wed, Oct 9, 2019 at 1:46 PM Jon Haddad wrote: > >> Seems reasonable, especially since we're in alpha mode. >> >> On Wed, Oct 9, 2019 at 10:28 AM Aleksey Yeshchenko >> wrote: >> >>> +1; in particular since the protocol itself is still in beta >>> On 9 Oct 2019, at 17:26, Oleksandr Petrov >>> wrote: Hi, During NGCC/ACNA19 we've had quite a few conversations around the 4.0 release. Many (minor) features and changes suggested during that time >> are possible to implement in 4.next without any problem. However, some >>> changes that seem to be very important for the community, which got mentioned >> in several conversations, are not possible to implement without protocol changes. By *protocol* changes here I mean both native and client >>> protocol. Here's a shortlist of the issues in question: https://issues.apache.org/jira/browse/CASSANDRA-15349 Add “Going away” message to the client protocol https://issues.apache.org/jira/browse/CASSANDRA-15350 Add CAS >>> “uncertainty” and “contention" messages that are currently propagated as a WriteTimeoutException. https://issues.apache.org/jira/browse/CASSANDRA-15351 Allow >> configuring timeouts on the per-request basis https://issues.apache.org/jira/browse/CASSANDRA-15352 Replica failure propagation to coordinator and client https://issues.apache.org/jira/browse/CASSANDRA-15299 Improve >>> checksumming and compression in protocol v5-beta And, less importantly - CASSANDRA-14683 (paging state issue). My suggestion would be to lift a freeze for all (or at least some) of >>> these issues, since they seem to be quite important for operators and each >> one >>> of them is extremely low risk, which means that any validation effort that >>> has already happened won't have to be re-done. All of the issues are fairly easy to implement, which means they won't delay the release. To my best knowledge, there's no client that fully supports 4.0, I >> think doing this now actually makes sense, meaning that driver implementers >>> won't really have to redo anything. Your thoughts on this are welcome, -- Alex >>> >>> >>> - >>> 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: Protocol-impacting (internode and client) changes for 4.0
> > each one of them is extremely low risk, which means that any validation > effort that has already happened won't have to be re-done +1 On Wed, Oct 9, 2019 at 1:46 PM Jon Haddad wrote: > Seems reasonable, especially since we're in alpha mode. > > On Wed, Oct 9, 2019 at 10:28 AM Aleksey Yeshchenko > wrote: > > > +1; in particular since the protocol itself is still in beta > > > > > On 9 Oct 2019, at 17:26, Oleksandr Petrov > > wrote: > > > > > > Hi, > > > > > > During NGCC/ACNA19 we've had quite a few conversations around the 4.0 > > > release. Many (minor) features and changes suggested during that time > are > > > possible to implement in 4.next without any problem. However, some > > changes > > > that seem to be very important for the community, which got mentioned > in > > > several conversations, are not possible to implement without protocol > > > changes. By *protocol* changes here I mean both native and client > > protocol. > > > > > > Here's a shortlist of the issues in question: > > > https://issues.apache.org/jira/browse/CASSANDRA-15349 Add “Going away” > > > message to the client protocol > > > https://issues.apache.org/jira/browse/CASSANDRA-15350 Add CAS > > “uncertainty” > > > and “contention" messages that are currently propagated as a > > > WriteTimeoutException. > > > https://issues.apache.org/jira/browse/CASSANDRA-15351 Allow > configuring > > > timeouts on the per-request basis > > > https://issues.apache.org/jira/browse/CASSANDRA-15352 Replica failure > > > propagation to coordinator and client > > > https://issues.apache.org/jira/browse/CASSANDRA-15299 Improve > > checksumming > > > and compression in protocol v5-beta > > > > > > And, less importantly - CASSANDRA-14683 (paging state issue). > > > > > > My suggestion would be to lift a freeze for all (or at least some) of > > these > > > issues, since they seem to be quite important for operators and each > one > > of > > > them is extremely low risk, which means that any validation effort that > > has > > > already happened won't have to be re-done. All of the issues are fairly > > > easy to implement, which means they won't delay the release. > > > > > > To my best knowledge, there's no client that fully supports 4.0, I > think > > > doing this now actually makes sense, meaning that driver implementers > > won't > > > really have to redo anything. > > > > > > Your thoughts on this are welcome, > > > -- Alex > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
Re: Protocol-impacting (internode and client) changes for 4.0
Seems reasonable, especially since we're in alpha mode. On Wed, Oct 9, 2019 at 10:28 AM Aleksey Yeshchenko wrote: > +1; in particular since the protocol itself is still in beta > > > On 9 Oct 2019, at 17:26, Oleksandr Petrov > wrote: > > > > Hi, > > > > During NGCC/ACNA19 we've had quite a few conversations around the 4.0 > > release. Many (minor) features and changes suggested during that time are > > possible to implement in 4.next without any problem. However, some > changes > > that seem to be very important for the community, which got mentioned in > > several conversations, are not possible to implement without protocol > > changes. By *protocol* changes here I mean both native and client > protocol. > > > > Here's a shortlist of the issues in question: > > https://issues.apache.org/jira/browse/CASSANDRA-15349 Add “Going away” > > message to the client protocol > > https://issues.apache.org/jira/browse/CASSANDRA-15350 Add CAS > “uncertainty” > > and “contention" messages that are currently propagated as a > > WriteTimeoutException. > > https://issues.apache.org/jira/browse/CASSANDRA-15351 Allow configuring > > timeouts on the per-request basis > > https://issues.apache.org/jira/browse/CASSANDRA-15352 Replica failure > > propagation to coordinator and client > > https://issues.apache.org/jira/browse/CASSANDRA-15299 Improve > checksumming > > and compression in protocol v5-beta > > > > And, less importantly - CASSANDRA-14683 (paging state issue). > > > > My suggestion would be to lift a freeze for all (or at least some) of > these > > issues, since they seem to be quite important for operators and each one > of > > them is extremely low risk, which means that any validation effort that > has > > already happened won't have to be re-done. All of the issues are fairly > > easy to implement, which means they won't delay the release. > > > > To my best knowledge, there's no client that fully supports 4.0, I think > > doing this now actually makes sense, meaning that driver implementers > won't > > really have to redo anything. > > > > Your thoughts on this are welcome, > > -- Alex > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: Protocol-impacting (internode and client) changes for 4.0
+1; in particular since the protocol itself is still in beta > On 9 Oct 2019, at 17:26, Oleksandr Petrov wrote: > > Hi, > > During NGCC/ACNA19 we've had quite a few conversations around the 4.0 > release. Many (minor) features and changes suggested during that time are > possible to implement in 4.next without any problem. However, some changes > that seem to be very important for the community, which got mentioned in > several conversations, are not possible to implement without protocol > changes. By *protocol* changes here I mean both native and client protocol. > > Here's a shortlist of the issues in question: > https://issues.apache.org/jira/browse/CASSANDRA-15349 Add “Going away” > message to the client protocol > https://issues.apache.org/jira/browse/CASSANDRA-15350 Add CAS “uncertainty” > and “contention" messages that are currently propagated as a > WriteTimeoutException. > https://issues.apache.org/jira/browse/CASSANDRA-15351 Allow configuring > timeouts on the per-request basis > https://issues.apache.org/jira/browse/CASSANDRA-15352 Replica failure > propagation to coordinator and client > https://issues.apache.org/jira/browse/CASSANDRA-15299 Improve checksumming > and compression in protocol v5-beta > > And, less importantly - CASSANDRA-14683 (paging state issue). > > My suggestion would be to lift a freeze for all (or at least some) of these > issues, since they seem to be quite important for operators and each one of > them is extremely low risk, which means that any validation effort that has > already happened won't have to be re-done. All of the issues are fairly > easy to implement, which means they won't delay the release. > > To my best knowledge, there's no client that fully supports 4.0, I think > doing this now actually makes sense, meaning that driver implementers won't > really have to redo anything. > > Your thoughts on this are welcome, > -- Alex - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Protocol-impacting (internode and client) changes for 4.0
+1 On 09/10/2019, 17:50, "Oleksandr Petrov" wrote: Hi, During NGCC/ACNA19 we've had quite a few conversations around the 4.0 release. Many (minor) features and changes suggested during that time are possible to implement in 4.next without any problem. However, some changes that seem to be very important for the community, which got mentioned in several conversations, are not possible to implement without protocol changes. By *protocol* changes here I mean both native and client protocol. Here's a shortlist of the issues in question: https://issues.apache.org/jira/browse/CASSANDRA-15349 Add “Going away” message to the client protocol https://issues.apache.org/jira/browse/CASSANDRA-15350 Add CAS “uncertainty” and “contention" messages that are currently propagated as a WriteTimeoutException. https://issues.apache.org/jira/browse/CASSANDRA-15351 Allow configuring timeouts on the per-request basis https://issues.apache.org/jira/browse/CASSANDRA-15352 Replica failure propagation to coordinator and client https://issues.apache.org/jira/browse/CASSANDRA-15299 Improve checksumming and compression in protocol v5-beta And, less importantly - CASSANDRA-14683 (paging state issue). My suggestion would be to lift a freeze for all (or at least some) of these issues, since they seem to be quite important for operators and each one of them is extremely low risk, which means that any validation effort that has already happened won't have to be re-done. All of the issues are fairly easy to implement, which means they won't delay the release. To my best knowledge, there's no client that fully supports 4.0, I think doing this now actually makes sense, meaning that driver implementers won't really have to redo anything. Your thoughts on this are welcome, -- Alex - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Protocol-impacting (internode and client) changes for 4.0
Hi, During NGCC/ACNA19 we've had quite a few conversations around the 4.0 release. Many (minor) features and changes suggested during that time are possible to implement in 4.next without any problem. However, some changes that seem to be very important for the community, which got mentioned in several conversations, are not possible to implement without protocol changes. By *protocol* changes here I mean both native and client protocol. Here's a shortlist of the issues in question: https://issues.apache.org/jira/browse/CASSANDRA-15349 Add “Going away” message to the client protocol https://issues.apache.org/jira/browse/CASSANDRA-15350 Add CAS “uncertainty” and “contention" messages that are currently propagated as a WriteTimeoutException. https://issues.apache.org/jira/browse/CASSANDRA-15351 Allow configuring timeouts on the per-request basis https://issues.apache.org/jira/browse/CASSANDRA-15352 Replica failure propagation to coordinator and client https://issues.apache.org/jira/browse/CASSANDRA-15299 Improve checksumming and compression in protocol v5-beta And, less importantly - CASSANDRA-14683 (paging state issue). My suggestion would be to lift a freeze for all (or at least some) of these issues, since they seem to be quite important for operators and each one of them is extremely low risk, which means that any validation effort that has already happened won't have to be re-done. All of the issues are fairly easy to implement, which means they won't delay the release. To my best knowledge, there's no client that fully supports 4.0, I think doing this now actually makes sense, meaning that driver implementers won't really have to redo anything. Your thoughts on this are welcome, -- Alex
