Re: Problem in updating schema in Cassandra 3.11.4
Does anyone has any ideas? On 2020/08/31 10:07:30, weiliang zhang<394693...@qq.com> wrote: > Hi everyone, I found that cassandra will first flush new schema to disk and > then change in memory while updating schema in Cassandra3.11.4 > (SchemaKeyspace.java:1378) . > But it seems that cassandra will only validate the schema while changing in > memory, and will not validate before flush to disk. > I don't know why not validate before flushing to disk ? Some request will > succeed in updating schema to disk and fail to update schema in memory, which > will make the schema in disk and schema in memory are not consistent. > > - > 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
CVE-2020-13946 Apache Cassandra RMI Rebind Vulnerability
CVE-2020-13946 Apache Cassandra RMI Rebind Vulnerability Versions Affected: All versions prior to: 2.1.22, 2.2.18, 3.0.22, 3.11.8 and 4.0-beta2 Description: It is possible for a local attacker without access to the Apache Cassandra process or configuration files to manipulate the RMI registry to perform a man-in-the-middle attack and capture user names and passwords used to access the JMX interface. The attacker can then use these credentials to access the JMX interface and perform unauthorised operations. Users should also be aware of CVE-2019-2684, a JRE vulnerability that enables this issue to be exploited remotely. Mitigation: 2.1.x users should upgrade to 2.1.22 2.2.x users should upgrade to 2.2.18 3.0.x users should upgrade to 3.0.22 3.11.x users should upgrade to 3.11.8 4.0-beta1 users should upgrade to 4.0-beta2
Re: Problem in updating schema in Cassandra 3.11.4
Hi, Could you precise what you mean by " will only validate the schema while changing in memory, and will not validate before flush to disk.". It is unclear to me of which validation you are talking about. On Tue, Sep 1, 2020 at 1:44 PM Weiliang Zhang <394693...@qq.com> wrote: > Does anyone has any ideas? > > On 2020/08/31 10:07:30, weiliang zhang<394693...@qq.com> wrote: > > Hi everyone, I found that cassandra will first flush new schema to disk > and then change in memory while updating schema in Cassandra3.11.4 > (SchemaKeyspace.java:1378) . > > But it seems that cassandra will only validate the schema while changing > in memory, and will not validate before flush to disk. > > I don't know why not validate before flushing to disk ? Some request > will succeed in updating schema to disk and fail to update schema in > memory, which will make the schema in disk and schema in memory are not > consistent. > > > > - > > 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: Problem in updating schema in Cassandra 3.11.4
I’m reasonably certain that this is one of the things that I fixed in 4.0. It’d be too invasive a change for 3.11, unfortunately. > On 1 Sep 2020, at 16:52, Benjamin Lerer wrote: > > Hi, > > Could you precise what you mean by " will only validate the schema while > changing in memory, and will not validate before flush to disk.". It is > unclear to me of which validation you are talking about. > > > > > > On Tue, Sep 1, 2020 at 1:44 PM Weiliang Zhang <394693...@qq.com> wrote: > >> Does anyone has any ideas? >> >> On 2020/08/31 10:07:30, weiliang zhang<394693...@qq.com> wrote: >>> Hi everyone, I found that cassandra will first flush new schema to disk >> and then change in memory while updating schema in Cassandra3.11.4 >> (SchemaKeyspace.java:1378) . >>> But it seems that cassandra will only validate the schema while changing >> in memory, and will not validate before flush to disk. >>> I don't know why not validate before flushing to disk ? Some request >> will succeed in updating schema to disk and fail to update schema in >> memory, which will make the schema in disk and schema in memory are not >> consistent. >>> >>> - >>> 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: cassandra.logdir
Go for it!
On Mon, Aug 31, 2020 at 10:23 PM Cyril Scetbon
wrote:
> Hey guys,
>
> Experimenting with Cassandra 4.0 I’m seeing that when CASSANDRA_LOG_DIR is
> set and ${cassandra.logdir} is used in logback.xml nodetool doesn’t use the
> env variable. It’s different for cassandra for instance
> https://github.com/apache/cassandra/blob/324267b3c0676ad31bd4f2fac0e2e673a9257a37/bin/cassandra#L186
> <
> https://github.com/apache/cassandra/blob/324267b3c0676ad31bd4f2fac0e2e673a9257a37/bin/cassandra#L186>.
> I feel like it should be added to
> https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/bin/nodetool
> <
> https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/bin/nodetool>,
> any objection to creating a ticket to do it ?
>
> Thanks
> —
> Cyril
>
>
[DISCUSS] Change style guide to recommend use of @Override
Currently our style guide recommends to avoid using @Override and updates intellij's code style to exclude it by default; I would like to propose we change this recommendation to use it and to update intellij's style to include it by default. @Override is used by javac to enforce that a method is in fact overriding from an abstract class or an interface and if this stops being true (such as a refactor happens) then a compiler error is thrown; when we default to excluding, it makes it harder to detect that a refactor catches all implementations and can lead to subtle and hard to track down bugs. This proposal is for new code and would not be to go rewrite all code at once, but would recommend new code adopt this style, and to pull old code forward which is related to changes being made (similar to our stance on imports). If people are ok with this, I will file a JIRA, update the docs, and update intellij's formatting. Thanks for your time!
Re: [DISCUSS] Change style guide to recommend use of @Override
+1 > On Sep 1, 2020, at 11:27 AM, David Capwell wrote: > > Currently our style guide recommends to avoid using @Override and updates > intellij's code style to exclude it by default; I would like to propose we > change this recommendation to use it and to update intellij's style to > include it by default. > > @Override is used by javac to enforce that a method is in fact overriding > from an abstract class or an interface and if this stops being true (such > as a refactor happens) then a compiler error is thrown; when we default to > excluding, it makes it harder to detect that a refactor catches all > implementations and can lead to subtle and hard to track down bugs. > > This proposal is for new code and would not be to go rewrite all code at > once, but would recommend new code adopt this style, and to pull old code > forward which is related to changes being made (similar to our stance on > imports). > > If people are ok with this, I will file a JIRA, update the docs, and > update intellij's formatting. > > Thanks for your time! - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] Change style guide to recommend use of @Override
+1 On Wed, 2 Sep 2020 at 02:45, Dinesh Joshi wrote: > +1 > > > On Sep 1, 2020, at 11:27 AM, David Capwell wrote: > > > > Currently our style guide recommends to avoid using @Override and updates > > intellij's code style to exclude it by default; I would like to propose > we > > change this recommendation to use it and to update intellij's style to > > include it by default. > > > > @Override is used by javac to enforce that a method is in fact overriding > > from an abstract class or an interface and if this stops being true (such > > as a refactor happens) then a compiler error is thrown; when we default > to > > excluding, it makes it harder to detect that a refactor catches all > > implementations and can lead to subtle and hard to track down bugs. > > > > This proposal is for new code and would not be to go rewrite all code at > > once, but would recommend new code adopt this style, and to pull old code > > forward which is related to changes being made (similar to our stance on > > imports). > > > > If people are ok with this, I will file a JIRA, update the docs, and > > update intellij's formatting. > > > > Thanks for your time! > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: [DISCUSS] Change style guide to recommend use of @Override
+1 On Tue, Sep 1, 2020, 2:00 PM Jasonstack Zhao Yang wrote: > +1 > > On Wed, 2 Sep 2020 at 02:45, Dinesh Joshi wrote: > > > +1 > > > > > On Sep 1, 2020, at 11:27 AM, David Capwell wrote: > > > > > > Currently our style guide recommends to avoid using @Override and > updates > > > intellij's code style to exclude it by default; I would like to propose > > we > > > change this recommendation to use it and to update intellij's style to > > > include it by default. > > > > > > @Override is used by javac to enforce that a method is in fact > overriding > > > from an abstract class or an interface and if this stops being true > (such > > > as a refactor happens) then a compiler error is thrown; when we default > > to > > > excluding, it makes it harder to detect that a refactor catches all > > > implementations and can lead to subtle and hard to track down bugs. > > > > > > This proposal is for new code and would not be to go rewrite all code > at > > > once, but would recommend new code adopt this style, and to pull old > code > > > forward which is related to changes being made (similar to our stance > on > > > imports). > > > > > > If people are ok with this, I will file a JIRA, update the docs, and > > > update intellij's formatting. > > > > > > Thanks for your time! > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
Re: [DISCUSS] Change style guide to recommend use of @Override
+1 On 01/09/2020, 20:09, "Caleb Rackliffe" wrote: +1 On Tue, Sep 1, 2020, 2:00 PM Jasonstack Zhao Yang wrote: > +1 > > On Wed, 2 Sep 2020 at 02:45, Dinesh Joshi wrote: > > > +1 > > > > > On Sep 1, 2020, at 11:27 AM, David Capwell wrote: > > > > > > Currently our style guide recommends to avoid using @Override and > updates > > > intellij's code style to exclude it by default; I would like to propose > > we > > > change this recommendation to use it and to update intellij's style to > > > include it by default. > > > > > > @Override is used by javac to enforce that a method is in fact > overriding > > > from an abstract class or an interface and if this stops being true > (such > > > as a refactor happens) then a compiler error is thrown; when we default > > to > > > excluding, it makes it harder to detect that a refactor catches all > > > implementations and can lead to subtle and hard to track down bugs. > > > > > > This proposal is for new code and would not be to go rewrite all code > at > > > once, but would recommend new code adopt this style, and to pull old > code > > > forward which is related to changes being made (similar to our stance > on > > > imports). > > > > > > If people are ok with this, I will file a JIRA, update the docs, and > > > update intellij's formatting. > > > > > > Thanks for your time! > > > > > > - > > 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: [DISCUSS] Change style guide to recommend use of @Override
+1 From: Caleb Rackliffe Sent: Tuesday, September 1, 2020 12:08:50 PM To: dev@cassandra.apache.org Subject: Re: [DISCUSS] Change style guide to recommend use of @Override +1 On Tue, Sep 1, 2020, 2:00 PM Jasonstack Zhao Yang wrote: > +1 > > On Wed, 2 Sep 2020 at 02:45, Dinesh Joshi wrote: > > > +1 > > > > > On Sep 1, 2020, at 11:27 AM, David Capwell wrote: > > > > > > Currently our style guide recommends to avoid using @Override and > updates > > > intellij's code style to exclude it by default; I would like to propose > > we > > > change this recommendation to use it and to update intellij's style to > > > include it by default. > > > > > > @Override is used by javac to enforce that a method is in fact > overriding > > > from an abstract class or an interface and if this stops being true > (such > > > as a refactor happens) then a compiler error is thrown; when we default > > to > > > excluding, it makes it harder to detect that a refactor catches all > > > implementations and can lead to subtle and hard to track down bugs. > > > > > > This proposal is for new code and would not be to go rewrite all code > at > > > once, but would recommend new code adopt this style, and to pull old > code > > > forward which is related to changes being made (similar to our stance > on > > > imports). > > > > > > If people are ok with this, I will file a JIRA, update the docs, and > > > update intellij's formatting. > > > > > > Thanks for your time! > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
Re: [DISCUSS] Change style guide to recommend use of @Override
+1 On Tue, Sep 1, 2020 at 12:22 PM Benedict Elliott Smith wrote: > +1 > > > > On 01/09/2020, 20:09, "Caleb Rackliffe" wrote: > > > > +1 > > > > On Tue, Sep 1, 2020, 2:00 PM Jasonstack Zhao Yang < > jasonstack.z...@gmail.com> > > wrote: > > > > > +1 > > > > > > On Wed, 2 Sep 2020 at 02:45, Dinesh Joshi wrote: > > > > > > > +1 > > > > > > > > > On Sep 1, 2020, at 11:27 AM, David Capwell > wrote: > > > > > > > > > > Currently our style guide recommends to avoid using @Override and > > > updates > > > > > intellij's code style to exclude it by default; I would like to > propose > > > > we > > > > > change this recommendation to use it and to update intellij's > style to > > > > > include it by default. > > > > > > > > > > @Override is used by javac to enforce that a method is in fact > > > overriding > > > > > from an abstract class or an interface and if this stops being > true > > > (such > > > > > as a refactor happens) then a compiler error is thrown; when we > default > > > > to > > > > > excluding, it makes it harder to detect that a refactor catches > all > > > > > implementations and can lead to subtle and hard to track down > bugs. > > > > > > > > > > This proposal is for new code and would not be to go rewrite all > code > > > at > > > > > once, but would recommend new code adopt this style, and to pull > old > > > code > > > > > forward which is related to changes being made (similar to our > stance > > > on > > > > > imports). > > > > > > > > > > If people are ok with this, I will file a JIRA, update the docs, > and > > > > > update intellij's formatting. > > > > > > > > > > Thanks for your time! > > > > > > > > > > > > > - > > > > 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: [DISCUSS] Change style guide to recommend use of @Override
+1 On Tue, Sep 1, 2020 at 6:26 PM Jordan West wrote: > +1 > > On Tue, Sep 1, 2020 at 12:22 PM Benedict Elliott Smith < > bened...@apache.org> > wrote: > > > +1 > > > > > > > > On 01/09/2020, 20:09, "Caleb Rackliffe" > wrote: > > > > > > > > +1 > > > > > > > > On Tue, Sep 1, 2020, 2:00 PM Jasonstack Zhao Yang < > > jasonstack.z...@gmail.com> > > > > wrote: > > > > > > > > > +1 > > > > > > > > > > On Wed, 2 Sep 2020 at 02:45, Dinesh Joshi > wrote: > > > > > > > > > > > +1 > > > > > > > > > > > > > On Sep 1, 2020, at 11:27 AM, David Capwell > > > wrote: > > > > > > > > > > > > > > Currently our style guide recommends to avoid using @Override > and > > > > > updates > > > > > > > intellij's code style to exclude it by default; I would like to > > propose > > > > > > we > > > > > > > change this recommendation to use it and to update intellij's > > style to > > > > > > > include it by default. > > > > > > > > > > > > > > @Override is used by javac to enforce that a method is in fact > > > > > overriding > > > > > > > from an abstract class or an interface and if this stops being > > true > > > > > (such > > > > > > > as a refactor happens) then a compiler error is thrown; when we > > default > > > > > > to > > > > > > > excluding, it makes it harder to detect that a refactor catches > > all > > > > > > > implementations and can lead to subtle and hard to track down > > bugs. > > > > > > > > > > > > > > This proposal is for new code and would not be to go rewrite > all > > code > > > > > at > > > > > > > once, but would recommend new code adopt this style, and to > pull > > old > > > > > code > > > > > > > forward which is related to changes being made (similar to our > > stance > > > > > on > > > > > > > imports). > > > > > > > > > > > > > > If people are ok with this, I will file a JIRA, update the > docs, > > and > > > > > > > update intellij's formatting. > > > > > > > > > > > > > > Thanks for your time! > > > > > > > > > > > > > > > > > > > > - > > > > > > 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: [DISCUSS] Change style guide to recommend use of @Override
+1 On 2/9/20 5:09, Joshua McKenzie wrote: > +1 > > On Tue, Sep 1, 2020 at 6:26 PM Jordan West wrote: > >> +1 >> >> On Tue, Sep 1, 2020 at 12:22 PM Benedict Elliott Smith < >> bened...@apache.org> >> wrote: >> >>> +1 >>> >>> >>> >>> On 01/09/2020, 20:09, "Caleb Rackliffe" >> wrote: >>> >>> >>> +1 >>> >>> >>> >>> On Tue, Sep 1, 2020, 2:00 PM Jasonstack Zhao Yang < >>> jasonstack.z...@gmail.com> >>> >>> wrote: >>> >>> >>> >>> > +1 >>> >>> > >>> >>> > On Wed, 2 Sep 2020 at 02:45, Dinesh Joshi >> wrote: >>> > >>> >>> > > +1 >>> >>> > > >>> >>> > > > On Sep 1, 2020, at 11:27 AM, David Capwell >> >>> wrote: >>> >>> > > > >>> >>> > > > Currently our style guide recommends to avoid using @Override >> and >>> > updates >>> >>> > > > intellij's code style to exclude it by default; I would like to >>> propose >>> >>> > > we >>> >>> > > > change this recommendation to use it and to update intellij's >>> style to >>> >>> > > > include it by default. >>> >>> > > > >>> >>> > > > @Override is used by javac to enforce that a method is in fact >>> >>> > overriding >>> >>> > > > from an abstract class or an interface and if this stops being >>> true >>> >>> > (such >>> >>> > > > as a refactor happens) then a compiler error is thrown; when we >>> default >>> >>> > > to >>> >>> > > > excluding, it makes it harder to detect that a refactor catches >>> all >>> >>> > > > implementations and can lead to subtle and hard to track down >>> bugs. >>> >>> > > > >>> >>> > > > This proposal is for new code and would not be to go rewrite >> all >>> code >>> >>> > at >>> >>> > > > once, but would recommend new code adopt this style, and to >> pull >>> old >>> >>> > code >>> >>> > > > forward which is related to changes being made (similar to our >>> stance >>> >>> > on >>> >>> > > > imports). >>> >>> > > > >>> >>> > > > If people are ok with this, I will file a JIRA, update the >> docs, >>> and >>> >>> > > > update intellij's formatting. >>> >>> > > > >>> >>> > > > Thanks for your time! >>> >>> > > >>> >>> > > >>> >>> > > >>> - >>> >>> > > 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: Committing `CASSANDRA-13701 Lower default num_tokens` and the dtest slowdown…
Thanks Adam. Now that we have CASSANDRA-16079 created and work is proceeding, can we please commit CASSANDRA-13701? There are many clusters out there that use the default of 256 num_tokens and migrating to something more sane is a lot of work. It would also be very helpful for having reasonable defaults getting tested for the release. It's been a bad default for a long, long time and we need to get this in before we do more testing for the release. > On Aug 28, 2020, at 5:25 AM, Adam Holmberg wrote: > > After discussing with a few stakeholders it sounds like folks agree that > optimizing dtest speed is a worthy endeavor. What is less clear are > concrete things that should be done. Since a brainstorming session failed > to materialize on CASSANDRA-13701, we thought it would make sense to start > with an open analysis. > > A ticket[1] has been created for analysis and further follow-up. We welcome > any concrete ideas people already have in mind. > > Kind regards, > Adam Holmberg > > [1] https://issues.apache.org/jira/browse/CASSANDRA-16079 > > On Mon, Aug 24, 2020 at 12:17 PM Mick Semb Wever wrote: > >> I believe the speed of our CI runs >>> is of common interest. What do you think? Does this sound feasible? Who >> is >>> in?* >>> >> >> >> I agree. I'm in. I have some ideas to add to the mix. Thanks Ekaterina. >> > > > -- > Adam Holmberg > e. adam.holmb...@datastax.com > w. www.datastax.com - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
