High IOWaits after upgrade to 3.11.1

[Jaroslav Kameník]

Hi all,

we are running one small testing cluster on virtualized HW,
it had little higher IOWaits in past, but after upgrade to
C* 3.11.1 IOWaits grew up +- three times. Are there any
changes causing more agressive disc usage?

Thanks,

Jaroslav

V5 as a protocol beta version in 3.11

[Oleksandr Petrov]

Hi everyone,

Currently, 3.11 supports V5 as a protocol version. However, all new
features are now going to 4.0, which is going to be a new feature release.

Right now we have two v5 features:

   - CASSANDRA-10786 
   - CASSANDRA-12838 


#12838 is adding duration type, which is a nice addition. #10786 is also
useful, but is more of an edge cases for users with huge clusters and/or
frequent schema changes.

If we leave v5 in 3.11, we'll have to always backport all v5 features to
3.11. This is something that hasn't been done in #10786. So the question
is: are we ready to commit and support v5 in 3.11 "forever", or should we
stop until it went too far and remove v5 from 3.11 since it's still in beta
there.

Looking forward to hear your opinion,


-- 
Alex Petrov

Re: V5 as a protocol beta version in 3.11

[Jeremiah D Jordan]

My 2 cents.  When we added V5 to 3.x wasn’t it added as a beta protocol for 
tick/tock stuff and known that when a new version came out it would most 
possibly break the older releases V5 beta stuff? Or at the very least add new 
things to V5.  So I see no reason to need to add more new features to 3.11 v5.

-Jeremiah

> On Nov 7, 2017, at 9:41 AM, Oleksandr Petrov  
> wrote:
> 
> Hi everyone,
> 
> Currently, 3.11 supports V5 as a protocol version. However, all new
> features are now going to 4.0, which is going to be a new feature release.
> 
> Right now we have two v5 features:
> 
>   - CASSANDRA-10786 
>   - CASSANDRA-12838 
> 
> 
> #12838 is adding duration type, which is a nice addition. #10786 is also
> useful, but is more of an edge cases for users with huge clusters and/or
> frequent schema changes.
> 
> If we leave v5 in 3.11, we'll have to always backport all v5 features to
> 3.11. This is something that hasn't been done in #10786. So the question
> is: are we ready to commit and support v5 in 3.11 "forever", or should we
> stop until it went too far and remove v5 from 3.11 since it's still in beta
> there.
> 
> Looking forward to hear your opinion,
> 
> 
> -- 
> Alex Petrov


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: V5 as a protocol beta version in 3.11

[Jonathan Haddad]

The other option, to avoid having two different v5 implementations, is to
bump 4.0’s protocol version to 6.
On Tue, Nov 7, 2017 at 6:48 AM Jeremiah D Jordan 
wrote:

> My 2 cents.  When we added V5 to 3.x wasn’t it added as a beta protocol
> for tick/tock stuff and known that when a new version came out it would
> most possibly break the older releases V5 beta stuff? Or at the very least
> add new things to V5.  So I see no reason to need to add more new features
> to 3.11 v5.
>
> -Jeremiah
>
> > On Nov 7, 2017, at 9:41 AM, Oleksandr Petrov 
> wrote:
> >
> > Hi everyone,
> >
> > Currently, 3.11 supports V5 as a protocol version. However, all new
> > features are now going to 4.0, which is going to be a new feature
> release.
> >
> > Right now we have two v5 features:
> >
> >   - CASSANDRA-10786 <
> https://issues.apache.org/jira/browse/CASSANDRA-10786>
> >   - CASSANDRA-12838 <
> https://issues.apache.org/jira/browse/CASSANDRA-12838>
> >
> >
> > #12838 is adding duration type, which is a nice addition. #10786 is also
> > useful, but is more of an edge cases for users with huge clusters and/or
> > frequent schema changes.
> >
> > If we leave v5 in 3.11, we'll have to always backport all v5 features to
> > 3.11. This is something that hasn't been done in #10786. So the question
> > is: are we ready to commit and support v5 in 3.11 "forever", or should we
> > stop until it went too far and remove v5 from 3.11 since it's still in
> beta
> > there.
> >
> > Looking forward to hear your opinion,
> >
> >
> > --
> > Alex Petrov
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: V5 as a protocol beta version in 3.11

[Oleksandr Petrov]

This is an option, you're right. In this case v5 will have just one
feature, however, and the only feature (Duration type) should work with via
CustomTypes through v4.

Looks like the Jira numbers were off, so let me do it again:

In 3.11 we have:
  * CASSANDRA-12838 - Extend native protocol flags and add supported
versions to the SUPPORTED response
  * CASSANDRA-12142 - Add "beta" version native protocol flag
  * CASSANDRA-12850 - Add the duration type to the protocol V5 <-- (this
one should also work with v4)

In 4.0 we have
  * CASSANDRA-10786 - Include hash of result set metadata in prepared
statement id

And the options:

  * (1) remove v5 from 3.11 by reverting #12838 and #12142
  * (2) support v5 in 3.11 forever and backport #10786
  * (3) bump 4.0 version to v6 and make sure that #10786 is v6

Question with (1) is mostly whether or not we would like to cut another
version release because of (in essence) #12838 only, since #12142 is not
relevant in the context and #12850 will still work.



On Tue, Nov 7, 2017 at 4:19 PM Jonathan Haddad  wrote:

> The other option, to avoid having two different v5 implementations, is to
> bump 4.0’s protocol version to 6.
> On Tue, Nov 7, 2017 at 6:48 AM Jeremiah D Jordan <
> jeremiah.jor...@gmail.com>
> wrote:
>
> > My 2 cents.  When we added V5 to 3.x wasn’t it added as a beta protocol
> > for tick/tock stuff and known that when a new version came out it would
> > most possibly break the older releases V5 beta stuff? Or at the very
> least
> > add new things to V5.  So I see no reason to need to add more new
> features
> > to 3.11 v5.
> >
> > -Jeremiah
> >
> > > On Nov 7, 2017, at 9:41 AM, Oleksandr Petrov <
> oleksandr.pet...@gmail.com>
> > wrote:
> > >
> > > Hi everyone,
> > >
> > > Currently, 3.11 supports V5 as a protocol version. However, all new
> > > features are now going to 4.0, which is going to be a new feature
> > release.
> > >
> > > Right now we have two v5 features:
> > >
> > >   - CASSANDRA-10786 <
> > https://issues.apache.org/jira/browse/CASSANDRA-10786>
> > >   - CASSANDRA-12838 <
> > https://issues.apache.org/jira/browse/CASSANDRA-12838>
> > >
> > >
> > > #12838 is adding duration type, which is a nice addition. #10786 is
> also
> > > useful, but is more of an edge cases for users with huge clusters
> and/or
> > > frequent schema changes.
> > >
> > > If we leave v5 in 3.11, we'll have to always backport all v5 features
> to
> > > 3.11. This is something that hasn't been done in #10786. So the
> question
> > > is: are we ready to commit and support v5 in 3.11 "forever", or should
> we
> > > stop until it went too far and remove v5 from 3.11 since it's still in
> > beta
> > > there.
> > >
> > > Looking forward to hear your opinion,
> > >
> > >
> > > --
> > > Alex Petrov
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>
-- 
Alex Petrov

Re: V5 as a protocol beta version in 3.11

[J. D. Jordan]

Again. V5 beta in 3.11 was always meant to stop working when future things 
happened to V5 in the drivers and in C*.  I see no problem with leaving the 
beta V5, which is an opt in thing to try out, in 3.11 alone. 4.0 will have the 
full non beta V5 with extra stuff in it, and will not work with beta V5.
Nothing uses the beta V5 by default. It is an opt in thing to be used if you 
wanted to try out stuff early.

-Jeremiah

> On Nov 7, 2017, at 11:39 AM, Oleksandr Petrov  
> wrote:
> 
> This is an option, you're right. In this case v5 will have just one
> feature, however, and the only feature (Duration type) should work with via
> CustomTypes through v4.
> 
> Looks like the Jira numbers were off, so let me do it again:
> 
> In 3.11 we have:
>  * CASSANDRA-12838 - Extend native protocol flags and add supported
> versions to the SUPPORTED response
>  * CASSANDRA-12142 - Add "beta" version native protocol flag
>  * CASSANDRA-12850 - Add the duration type to the protocol V5 <-- (this
> one should also work with v4)
> 
> In 4.0 we have
>  * CASSANDRA-10786 - Include hash of result set metadata in prepared
> statement id
> 
> And the options:
> 
>  * (1) remove v5 from 3.11 by reverting #12838 and #12142
>  * (2) support v5 in 3.11 forever and backport #10786
>  * (3) bump 4.0 version to v6 and make sure that #10786 is v6
> 
> Question with (1) is mostly whether or not we would like to cut another
> version release because of (in essence) #12838 only, since #12142 is not
> relevant in the context and #12850 will still work.
> 
> 
> 
>> On Tue, Nov 7, 2017 at 4:19 PM Jonathan Haddad  wrote:
>> 
>> The other option, to avoid having two different v5 implementations, is to
>> bump 4.0’s protocol version to 6.
>> On Tue, Nov 7, 2017 at 6:48 AM Jeremiah D Jordan <
>> jeremiah.jor...@gmail.com>
>> wrote:
>> 
>>> My 2 cents.  When we added V5 to 3.x wasn’t it added as a beta protocol
>>> for tick/tock stuff and known that when a new version came out it would
>>> most possibly break the older releases V5 beta stuff? Or at the very
>> least
>>> add new things to V5.  So I see no reason to need to add more new
>> features
>>> to 3.11 v5.
>>> 
>>> -Jeremiah
>>> 
 On Nov 7, 2017, at 9:41 AM, Oleksandr Petrov <
>> oleksandr.pet...@gmail.com>
>>> wrote:
 
 Hi everyone,
 
 Currently, 3.11 supports V5 as a protocol version. However, all new
 features are now going to 4.0, which is going to be a new feature
>>> release.
 
 Right now we have two v5 features:
 
  - CASSANDRA-10786 <
>>> https://issues.apache.org/jira/browse/CASSANDRA-10786>
  - CASSANDRA-12838 <
>>> https://issues.apache.org/jira/browse/CASSANDRA-12838>
 
 
 #12838 is adding duration type, which is a nice addition. #10786 is
>> also
 useful, but is more of an edge cases for users with huge clusters
>> and/or
 frequent schema changes.
 
 If we leave v5 in 3.11, we'll have to always backport all v5 features
>> to
 3.11. This is something that hasn't been done in #10786. So the
>> question
 is: are we ready to commit and support v5 in 3.11 "forever", or should
>> we
 stop until it went too far and remove v5 from 3.11 since it's still in
>>> beta
 there.
 
 Looking forward to hear your opinion,
 
 
 --
 Alex Petrov
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>>> 
>> 
> -- 
> Alex Petrov

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: V5 as a protocol beta version in 3.11

[Adam Holmberg]

I agree that it is okay to leave v5 beta behind. As I recall, the point of
beta was less about trying stuff early, but more to allow early
implementation and testing of new protocol features, before the scope was
finalized. Now that v5 proper has diverged from beta it is no longer
supported. I don't see much value in back-porting, nor do I think we
should  increment versions in order to maintain compatibility with
something that was expressly beta.

I think we should disable v5 testing in 3.x branch and let the v5 spec
continue to evolve in *non-beta* status in 4.0 until it is finalized upon
release.

Adam Holmberg

On Tue, Nov 7, 2017 at 10:57 AM, J. D. Jordan 
wrote:

> Again. V5 beta in 3.11 was always meant to stop working when future things
> happened to V5 in the drivers and in C*.  I see no problem with leaving the
> beta V5, which is an opt in thing to try out, in 3.11 alone. 4.0 will have
> the full non beta V5 with extra stuff in it, and will not work with beta V5.
> Nothing uses the beta V5 by default. It is an opt in thing to be used if
> you wanted to try out stuff early.
>
> -Jeremiah
>
> > On Nov 7, 2017, at 11:39 AM, Oleksandr Petrov <
> oleksandr.pet...@gmail.com> wrote:
> >
> > This is an option, you're right. In this case v5 will have just one
> > feature, however, and the only feature (Duration type) should work with
> via
> > CustomTypes through v4.
> >
> > Looks like the Jira numbers were off, so let me do it again:
> >
> > In 3.11 we have:
> >  * CASSANDRA-12838 - Extend native protocol flags and add supported
> > versions to the SUPPORTED response
> >  * CASSANDRA-12142 - Add "beta" version native protocol flag
> >  * CASSANDRA-12850 - Add the duration type to the protocol V5 <-- (this
> > one should also work with v4)
> >
> > In 4.0 we have
> >  * CASSANDRA-10786 - Include hash of result set metadata in prepared
> > statement id
> >
> > And the options:
> >
> >  * (1) remove v5 from 3.11 by reverting #12838 and #12142
> >  * (2) support v5 in 3.11 forever and backport #10786
> >  * (3) bump 4.0 version to v6 and make sure that #10786 is v6
> >
> > Question with (1) is mostly whether or not we would like to cut another
> > version release because of (in essence) #12838 only, since #12142 is not
> > relevant in the context and #12850 will still work.
> >
> >
> >
> >> On Tue, Nov 7, 2017 at 4:19 PM Jonathan Haddad 
> wrote:
> >>
> >> The other option, to avoid having two different v5 implementations, is
> to
> >> bump 4.0’s protocol version to 6.
> >> On Tue, Nov 7, 2017 at 6:48 AM Jeremiah D Jordan <
> >> jeremiah.jor...@gmail.com>
> >> wrote:
> >>
> >>> My 2 cents.  When we added V5 to 3.x wasn’t it added as a beta protocol
> >>> for tick/tock stuff and known that when a new version came out it would
> >>> most possibly break the older releases V5 beta stuff? Or at the very
> >> least
> >>> add new things to V5.  So I see no reason to need to add more new
> >> features
> >>> to 3.11 v5.
> >>>
> >>> -Jeremiah
> >>>
>  On Nov 7, 2017, at 9:41 AM, Oleksandr Petrov <
> >> oleksandr.pet...@gmail.com>
> >>> wrote:
> 
>  Hi everyone,
> 
>  Currently, 3.11 supports V5 as a protocol version. However, all new
>  features are now going to 4.0, which is going to be a new feature
> >>> release.
> 
>  Right now we have two v5 features:
> 
>   - CASSANDRA-10786 <
> >>> https://issues.apache.org/jira/browse/CASSANDRA-10786>
>   - CASSANDRA-12838 <
> >>> https://issues.apache.org/jira/browse/CASSANDRA-12838>
> 
> 
>  #12838 is adding duration type, which is a nice addition. #10786 is
> >> also
>  useful, but is more of an edge cases for users with huge clusters
> >> and/or
>  frequent schema changes.
> 
>  If we leave v5 in 3.11, we'll have to always backport all v5 features
> >> to
>  3.11. This is something that hasn't been done in #10786. So the
> >> question
>  is: are we ready to commit and support v5 in 3.11 "forever", or should
> >> we
>  stop until it went too far and remove v5 from 3.11 since it's still in
> >>> beta
>  there.
> 
>  Looking forward to hear your opinion,
> 
> 
>  --
>  Alex Petrov
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>>
> >>>
> >>
> > --
> > Alex Petrov
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: High IOWaits after upgrade to 3.11.1

[Eric Evans]

On Tue, Nov 7, 2017 at 4:38 AM, Jaroslav Kameník  wrote:
> Hi all,
>
> we are running one small testing cluster on virtualized HW,
> it had little higher IOWaits in past, but after upgrade to
> C* 3.11.1 IOWaits grew up +- three times. Are there any
> changes causing more agressive disc usage?

What version are you upgrading from?

How many page faults are you seeing?  If the number is high, you might
try adding "disk_access_mode: mmap_index_only" to cassandra.yaml
(there is no default entry in the file).


-- 
Eric Evans
john.eric.ev...@gmail.com

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: V5 as a protocol beta version in 3.11

[Alex P]

This makes sense and is alongside with the previous discussions about v5. I 
agree with Adam and Jeremiah on that.

Thank you for the input. I will adjust the tests tomorrow.

Best regards,
Alex Petrov

> On 7. Nov 2017, at 18:32, Adam Holmberg  wrote:
> 
> I agree that it is okay to leave v5 beta behind. As I recall, the point of
> beta was less about trying stuff early, but more to allow early
> implementation and testing of new protocol features, before the scope was
> finalized. Now that v5 proper has diverged from beta it is no longer
> supported. I don't see much value in back-porting, nor do I think we
> should  increment versions in order to maintain compatibility with
> something that was expressly beta.
> 
> I think we should disable v5 testing in 3.x branch and let the v5 spec
> continue to evolve in *non-beta* status in 4.0 until it is finalized upon
> release.
> 
> Adam Holmberg
> 
> On Tue, Nov 7, 2017 at 10:57 AM, J. D. Jordan 
> wrote:
> 
>> Again. V5 beta in 3.11 was always meant to stop working when future things
>> happened to V5 in the drivers and in C*.  I see no problem with leaving the
>> beta V5, which is an opt in thing to try out, in 3.11 alone. 4.0 will have
>> the full non beta V5 with extra stuff in it, and will not work with beta V5.
>> Nothing uses the beta V5 by default. It is an opt in thing to be used if
>> you wanted to try out stuff early.
>> 
>> -Jeremiah
>> 
>>> On Nov 7, 2017, at 11:39 AM, Oleksandr Petrov <
>> oleksandr.pet...@gmail.com> wrote:
>>> 
>>> This is an option, you're right. In this case v5 will have just one
>>> feature, however, and the only feature (Duration type) should work with
>> via
>>> CustomTypes through v4.
>>> 
>>> Looks like the Jira numbers were off, so let me do it again:
>>> 
>>> In 3.11 we have:
>>> * CASSANDRA-12838 - Extend native protocol flags and add supported
>>> versions to the SUPPORTED response
>>> * CASSANDRA-12142 - Add "beta" version native protocol flag
>>> * CASSANDRA-12850 - Add the duration type to the protocol V5 <-- (this
>>> one should also work with v4)
>>> 
>>> In 4.0 we have
>>> * CASSANDRA-10786 - Include hash of result set metadata in prepared
>>> statement id
>>> 
>>> And the options:
>>> 
>>> * (1) remove v5 from 3.11 by reverting #12838 and #12142
>>> * (2) support v5 in 3.11 forever and backport #10786
>>> * (3) bump 4.0 version to v6 and make sure that #10786 is v6
>>> 
>>> Question with (1) is mostly whether or not we would like to cut another
>>> version release because of (in essence) #12838 only, since #12142 is not
>>> relevant in the context and #12850 will still work.
>>> 
>>> 
>>> 
 On Tue, Nov 7, 2017 at 4:19 PM Jonathan Haddad 
>> wrote:
 
 The other option, to avoid having two different v5 implementations, is
>> to
 bump 4.0’s protocol version to 6.
 On Tue, Nov 7, 2017 at 6:48 AM Jeremiah D Jordan <
 jeremiah.jor...@gmail.com>
 wrote:
 
> My 2 cents.  When we added V5 to 3.x wasn’t it added as a beta protocol
> for tick/tock stuff and known that when a new version came out it would
> most possibly break the older releases V5 beta stuff? Or at the very
 least
> add new things to V5.  So I see no reason to need to add more new
 features
> to 3.11 v5.
> 
> -Jeremiah
> 
>> On Nov 7, 2017, at 9:41 AM, Oleksandr Petrov <
 oleksandr.pet...@gmail.com>
> wrote:
>> 
>> Hi everyone,
>> 
>> Currently, 3.11 supports V5 as a protocol version. However, all new
>> features are now going to 4.0, which is going to be a new feature
> release.
>> 
>> Right now we have two v5 features:
>> 
>> - CASSANDRA-10786 <
> https://issues.apache.org/jira/browse/CASSANDRA-10786>
>> - CASSANDRA-12838 <
> https://issues.apache.org/jira/browse/CASSANDRA-12838>
>> 
>> 
>> #12838 is adding duration type, which is a nice addition. #10786 is
 also
>> useful, but is more of an edge cases for users with huge clusters
 and/or
>> frequent schema changes.
>> 
>> If we leave v5 in 3.11, we'll have to always backport all v5 features
 to
>> 3.11. This is something that hasn't been done in #10786. So the
 question
>> is: are we ready to commit and support v5 in 3.11 "forever", or should
 we
>> stop until it went too far and remove v5 from 3.11 since it's still in
> beta
>> there.
>> 
>> Looking forward to hear your opinion,
>> 
>> 
>> --
>> Alex Petrov
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
> 
 
>>> --
>>> Alex Petrov
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>