Re: [DISCUSS] CEP-7 Storage Attached Index

[Jasonstack Zhao Yang]

Hi Duy, great questions.

> 1) SASI was pretty inefficient indexing wide partitions because the index
> structure only retains the partition token, not the clustering colums. As
> per design doc SAI has row id mapping to partition offset, can we hope
that
> indexing wide partition will be more efficient with SAI ? One detail that
> worries me is that in the beggining of the design doc, it is said that the
> matching rows are post filtered while scanning the partition. Can you
> confirm or infirm that SAI is efficient with wide partitions and provides
> the partition offsets to the matching rows ?

As of now, SAI indexes partition offset, same as SASI. But during design, we
have taken row-level-index into consideration and row-awareness is being
prototyped.

For the record, partition-level indexing works nicely when most rows in the
wide
partition match indexed value. After switching to row-level-index, when
matching
most rows in wide partition, the index engine needs to fall back to
partition-level
index behavior (scanning entire partition + post-filter) instead of
fetching single
rows many times.

> 2) About space efficiency, one of the biggest drawback of SASI was the
huge
> space required for index structure when using CONTAINS logic because of
the
> decomposition of text columns into n-grams. Will SAI suffer from the same
> issue in future iterations ? I'm anticipating a bit

Tokenization wasn't part of the CEP scope.

Off the top of my head, I think tokenization did require more space, as
both SAI and SASI
need to store matches for every decomposed value. But with
frame-of-reference encoding
on row ids, SAI should require less disk space than SASI.

> 3) If I'm querying using SAI and providing complete partition key, will it
> be more efficient than querying without partition key. In other words,
does
> SAI provide any optimisation when partition key is specified ?

Yes.

* On coordinator, it will find replicas with PK.
* On replica side:
 - it will skip to given PK token
 - there is some pruning based on min/max key of index segments.

> 4) Are collections, static columns, composite partition key composent and
> UDT indexings (at any depth) on the roadmap of SAI ? I strongly believe
> that those features are the bare minimum to make SAI an interesting
> replacement for the native 2nd index as well as SASI. SASI limited support
> for those advanced data structures has hindered its wide adoption (among
> other issues and bugs)

Collections, static columns, composite partition key are supported.

I think "UDT indexings (at any depth)" can be added because there is no
architectural limitation on SAI or SASI.

I have invited you to slack #cassandra-sai, really appreciate your
participation.


On Tue, 18 Aug 2020 at 19:33, DuyHai Doan  wrote:

> Last but not least
>
> 4) Are collections, static columns, composite partition key composent and
> UDT indexings (at any depth) on the roadmap of SAI ? I strongly believe
> that those features are the bare minimum to make SAI an interesting
> replacement for the native 2nd index as well as SASI. SASI limited support
> for those advanced data structures has hindered its wide adoption (among
> other issues and bugs)
>
> Regards
>
> Duy Hai DOAN
>
> Le mar. 18 août 2020 à 13:02, Jasonstack Zhao Yang <
> jasonstack.z...@gmail.com> a écrit :
>
> > Mick thanks for your questions.
> >
> > > During the 4.0 beta phase this was intended to be addressed, i.e.>
> > defining more specific QA guidelines for 4.0-rc. This would be an
> important
> > > step towards QA guidelines for all changes and CEPs post-4.0.
> >
> > Agreed, I think CASSANDRA-15536
> >  (4.0 Quality:
> > Components and Test Plans) has set a good example of QA/Testing.
> >
> > >  - How will this be tested, how will its QA status and lifecycle be>
> > defined? (per above)
> >
> > SAI will follow the same QA/Testing guideline as in CASSANDRA-15536.
> >
> > >  - With existing C* code needing to be changed, what is the proposed
> > plan> for making those changes ensuring maintained QA, e.g. is there
> > separate QA
> > > cycles planned for altering the SPI before adding a new SPI
> > implementation?
> >
> > The plan is to have interface changes and their new implementations to be
> > reviewed/tested/merged at once to reduce overhead.
> >
> > But if having interface changes reviewed/tested/merged separately helps
> > quality, I don't think anyone will object.
> >
> > > - Despite being out of scope, it would be nice to have some idea from
> > the>  CEP author of when users might still choose afresh 2i or SASI over
> > SAI
> >
> > I'd like SAI to be the only index for users, but this is a decision to be
> > made by the community.
> >
> > > - Who fills the roles involved?
> >
> > Contributors that are still active on C* or related projects:
> >
> > Andres de la Peña
> > Caleb Rackliffe
> > Dan LaRocque
> > Jason Rutherglen
> > Mike Adamson
> > Rocco Varela
> > Zhao 

Re: Cassandra Kubernetes SIG - status update

[Cyril Scetbon]

Hey Christopher,

Okay cause I also need the same as I use Jolokia 
https://github.com/Orange-OpenSource/casskop/blob/master/docker/bootstrap/files/run.sh#L192-L199
 


Should I add it to the issue I created or will you create another one ?

—
Cyril Scetbon

> On Aug 18, 2020, at 11:05 PM, Christopher Bradford  
> wrote:
> 
> It sounds like he just included the agent jar which has this class on the
> CLASSPATH. This feels like an enhancement for the definitions config
> builder uses to allow for configuration of the seed provider.
> 
> On Tue, Aug 18, 2020 at 11:00 PM Cyril Scetbon 
> wrote:
> 
>> Hey John,
>> 
>> 
>> 
>> I’m also in the middle of evaluating this image as I want to test
>> cassandra 4.0-beta1 and am trying to avoid having to handle changes at the
>> configuration level (deprecated/renamed parameters for instance). I also
>> have an issue with the fact the seed_provider class is not parameterized.
>> See https://github.com/datastax/cass-config-definitions/issues/19 <
>> https://github.com/datastax/cass-config-definitions/issues/19>.
>> 
>> 
>> 
>> Did you happen to fork the project with that change ?
>> 
>> 
>> 
>> Thanks
>> 
>> —
>> 
>> Cyril Scetbon
>> 
>> 
>> 
>>> On Aug 5, 2020, at 11:51 PM, John Sanda  wrote:
>> 
>>> 
>> 
>>> cass-config-builder configures Cassandra to
>> 
>>> use org.apache.cassandra.locator.K8SeedProvider. This class however is
>> 
>>> defined in management-api-for-apache-cassandra
>> 
>>> > https://github.com/datastax/management-api-for-apache-cassandra>>, i.e.,
>> 
>>> the DataStax management sidecar. I am not using the management sidecar
>> yet,
>> 
>>> but updated my C* image to include the agent JAR which contains the
>> 
>>> K8SeedProvider class. I am still trying to iron out some of the wrinkles.
>> 
>> 
>> 
>> --
> 
> Christopher Bradford

Committing `CASSANDRA-13701 Lower default num_tokens` and the dtest slowdown…

[Mick Semb Wever]

It was agreed¹ that 4.0 should have the new configuration defaults of
  num_tokens: 16
  allocate_tokens_for_local_replication_factor: 3

13701's patches: against cassandra, cassandra-builds, cassandra-dtest, ccm;
are reviewed, tested, and ready to commit. But the ccm and dtest patches
required ccm having to now start nodes sequentially, and adding some longer
timeout values in the dtests.

The consequence of this is CI runs now take longer. ci-cassandra.a.o's
dtests take ~30% longer, and circleci's dtests (with vnodes) have gone from
~22 to ~43 minutes. The general opinion (on slack²) is to commit, and work
on improving ccm and dtest startup times in a subsequent ticket.

13701 was intended to be committed before the first beta release because of
its user-facing changes. But these numbers are significant enough it makes
sense to touch base with dev@

Does anyone (strongly) object to the "commit + follow up ticket" approach?

regards,
Mick


¹ –
https://lists.apache.org/thread.html/ra829084fcf344e9e96fa5c61cb31e909c8629091993471594b65ea89%40%3Cdev.cassandra.apache.org%3E
² – https://the-asf.slack.com/archives/CK23JSY2K/p1597747395032600 and
https://the-asf.slack.com/archives/CK23JSY2K/p1597849774078200?thread_ts=1597762085.048300&cid=CK23JSY2K

Re: [DISCUSS] Revisiting Java 11's experimental status

[Joshua McKenzie]

>
> 3) during 4.0 qualification, issues found on jdk 11 should block the
> release

Maybe we let 2 run and see how many issues there are before we call release
blocking?



On Tue, Aug 18, 2020 at 10:05 PM David Capwell  wrote:

> I would propose the following:
>
> 1) leave jdk 11 marked as experimental
> 2) make sure CI runs jdk 8 and jdk 11 for all builds (circle / jenkins)
> 3) during 4.0 qualification, issues found on jdk 11 should block the
> release
>
> This should get us in good shape to potentially be ready to flip the switch
> in 4.1 or even 4.0.1; given that not everyone is signing up to test java
> 11, #3 might not be enough to fully mark stable.
>
> On Tue, Aug 18, 2020 at 6:10 PM Joshua McKenzie 
> wrote:
>
> > Where did we land on this? Don't seem to have a clear consensus from
> thread
> > discussion.
> >
> > On Mon, Jul 20, 2020 at 10:02 PM Deepak Vohra  >
> > wrote:
> >
> > >  The same link was posted earlier also.
> > > For Java 8 and 11 the poll result is very similar.
> > > Java 8 =58.4%Java 11 =22.56%
> > >
> > >
> > > On Monday, July 20, 2020, 04:38:03 p.m. PDT, Joshua McKenzie <
> > > jmcken...@apache.org> wrote:
> > >
> > >  That's remarkably close to the jrebel results for 2020:
> > >
> > > https://www.jrebel.com/blog/2020-java-technology-report#java-version
> > >
> > >  Came across this this past weekend doing unrelated research; can't
> vouch
> > > for the accuracy / methods / etc.
> > >
> > >
> > > On Mon, Jul 20, 2020 at 7:32 PM Jeff Jirsa  wrote:
> > >
> > > > Got it, thanks for the correction.
> > > >
> > > >
> > > > On Mon, Jul 20, 2020 at 4:28 PM Brandon Williams 
> > > wrote:
> > > >
> > > > > I believe you can run them on 11, but you can't build them on it.
> > > > >
> > > > > On Mon, Jul 20, 2020 at 6:11 PM Jeff Jirsa 
> wrote:
> > > > > >
> > > > > > I still dont get it, because you can't use any released version
> of
> > > > > > cassandra with anything other than jdk8.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, Jul 20, 2020 at 2:50 PM Patrick McFadin <
> > pmcfa...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > Follow-up on the informal poll I did on twitter:
> > > > > > >
> > https://twitter.com/patrickmcfadin/status/1282791302065557504?s=21
> > > > > > >
> > > > > > > Offered up as data to be used as you will.
> > > > > > >
> > > > > > > 161 votes
> > > > > > > <= JDK8: 59%
> > > > > > > JDK9 or 10: 7%
> > > > > > > JDK11 or 12: 27%
> > > > > > > JDK13 or 14: 7%
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Jul 15, 2020 at 3:19 AM Robert Stupp 
> > > wrote:
> > > > > > >
> > > > > > > > Yea, ZGC is kinda tricky in 11.
> > > > > > > >
> > > > > > > > —
> > > > > > > > Robert Stupp
> > > > > > > > @snazy
> > > > > > > >
> > > > > > > > > On 14. Jul 2020, at 15:02, Jeff Jirsa 
> > > wrote:
> > > > > > > > >
> > > > > > > > > Zgc
> > > > > > > > >
> > > > > > > > >> On Jul 14, 2020, at 2:26 AM, Robert Stupp  >
> > > > wrote:
> > > > > > > > >>
> > > > > > > > >> 
> > > > > > > > >>> On 14. Jul 2020, at 07:33, Jeff Jirsa 
> > > > wrote:
> > > > > > > > >>>
> > > > > > > > >>> Perhaps the most notable parts of jdk11 (for cassandra)
> > > aren’t
> > > > > even
> > > > > > > > prod ready in jdk11 , so what’s the motivation and what does
> > the
> > > > > project
> > > > > > > > gain from revisiting the experimental designation on jdk11?
> > > > > > > > >>
> > > > > > > > >> Can you elaborate on what’s not even prod ready in Java
> 11?
> > > > > > > > >
> > > > > > > > >
> > > > >
> -
> > > > > > > > > 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] Revisiting Java 11's experimental status

[David Capwell]

My statement was more coming from the fact that if we test on java 8 and
find an issue it is a release blocker, so saying java 11 should be treated
with the same regard as java 8 when it comes to filing/fixing issues; when
it comes to filing and fixing issues, we shouldn't have different stances
on different JVMs.  I don't want us to say "java 11 is experimental, so
lets ignore issue X", we will have a hard time getting out of
experimental if we have this stance.

Now, don't get me wrong.  If something is very specific to java 11 and we
can reason that the impact to users is near zero, I am fine not marking the
issue as a release blocker.  An example is that jvm dtests crash the JVM
because of a race condition with CMS and class unloading, this issue
shouldn't block the release but we should still find a way to make it
stable (changed flags when running tests on java 11 to avoid the issue).

With regard to #2, we have a ways to go to get CI on-par but there is
traction already on both fronts.  I run the java (not python) suite on java
11 frequently and see that known flaky tests are still flaky on java 11,
though the suite tends to pass with enough retries.


On Wed, Aug 19, 2020 at 9:51 AM Joshua McKenzie 
wrote:

> >
> > 3) during 4.0 qualification, issues found on jdk 11 should block the
> > release
>
> Maybe we let 2 run and see how many issues there are before we call release
> blocking?
>
>
>
> On Tue, Aug 18, 2020 at 10:05 PM David Capwell  wrote:
>
> > I would propose the following:
> >
> > 1) leave jdk 11 marked as experimental
> > 2) make sure CI runs jdk 8 and jdk 11 for all builds (circle / jenkins)
> > 3) during 4.0 qualification, issues found on jdk 11 should block the
> > release
> >
> > This should get us in good shape to potentially be ready to flip the
> switch
> > in 4.1 or even 4.0.1; given that not everyone is signing up to test java
> > 11, #3 might not be enough to fully mark stable.
> >
> > On Tue, Aug 18, 2020 at 6:10 PM Joshua McKenzie 
> > wrote:
> >
> > > Where did we land on this? Don't seem to have a clear consensus from
> > thread
> > > discussion.
> > >
> > > On Mon, Jul 20, 2020 at 10:02 PM Deepak Vohra
>  > >
> > > wrote:
> > >
> > > >  The same link was posted earlier also.
> > > > For Java 8 and 11 the poll result is very similar.
> > > > Java 8 =58.4%Java 11 =22.56%
> > > >
> > > >
> > > > On Monday, July 20, 2020, 04:38:03 p.m. PDT, Joshua McKenzie <
> > > > jmcken...@apache.org> wrote:
> > > >
> > > >  That's remarkably close to the jrebel results for 2020:
> > > >
> > > > https://www.jrebel.com/blog/2020-java-technology-report#java-version
> > > >
> > > >  Came across this this past weekend doing unrelated research; can't
> > vouch
> > > > for the accuracy / methods / etc.
> > > >
> > > >
> > > > On Mon, Jul 20, 2020 at 7:32 PM Jeff Jirsa  wrote:
> > > >
> > > > > Got it, thanks for the correction.
> > > > >
> > > > >
> > > > > On Mon, Jul 20, 2020 at 4:28 PM Brandon Williams  >
> > > > wrote:
> > > > >
> > > > > > I believe you can run them on 11, but you can't build them on it.
> > > > > >
> > > > > > On Mon, Jul 20, 2020 at 6:11 PM Jeff Jirsa 
> > wrote:
> > > > > > >
> > > > > > > I still dont get it, because you can't use any released version
> > of
> > > > > > > cassandra with anything other than jdk8.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Mon, Jul 20, 2020 at 2:50 PM Patrick McFadin <
> > > pmcfa...@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > Follow-up on the informal poll I did on twitter:
> > > > > > > >
> > > https://twitter.com/patrickmcfadin/status/1282791302065557504?s=21
> > > > > > > >
> > > > > > > > Offered up as data to be used as you will.
> > > > > > > >
> > > > > > > > 161 votes
> > > > > > > > <= JDK8: 59%
> > > > > > > > JDK9 or 10: 7%
> > > > > > > > JDK11 or 12: 27%
> > > > > > > > JDK13 or 14: 7%
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Jul 15, 2020 at 3:19 AM Robert Stupp  >
> > > > wrote:
> > > > > > > >
> > > > > > > > > Yea, ZGC is kinda tricky in 11.
> > > > > > > > >
> > > > > > > > > —
> > > > > > > > > Robert Stupp
> > > > > > > > > @snazy
> > > > > > > > >
> > > > > > > > > > On 14. Jul 2020, at 15:02, Jeff Jirsa 
> > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Zgc
> > > > > > > > > >
> > > > > > > > > >> On Jul 14, 2020, at 2:26 AM, Robert Stupp <
> sn...@snazy.de
> > >
> > > > > wrote:
> > > > > > > > > >>
> > > > > > > > > >> 
> > > > > > > > > >>> On 14. Jul 2020, at 07:33, Jeff Jirsa <
> jji...@gmail.com>
> > > > > wrote:
> > > > > > > > > >>>
> > > > > > > > > >>> Perhaps the most notable parts of jdk11 (for cassandra)
> > > > aren’t
> > > > > > even
> > > > > > > > > prod ready in jdk11 , so what’s the motivation and what
> does
> > > the
> > > > > > project
> > > > > > > > > gain from revisiting the experimental designation on jdk11?
> > > > > > > > > >>
> > > > > > > > > >> Can you elaborate on what’s not even prod ready in Java
> > 11?
> > > > 

Re: [DISCUSS] Revisiting Java 11's experimental status

[Joshua McKenzie]

>
> java 11 is experimental, so lets ignore issue X

s/ignore/defer until after 4.0 GA/g (semantic difference that may not sway
you)

If we block the release on JDK11 issues we find, it *seems* to me that
that's the same as saying "JDK11 is supported" assuming we have the same a)
level of testing and b) stance on found defects for JDK8 as we have for
JDK11. Which I'm totally fine with fwiw.

What in my mental model here ^ doesn't match yours? :) Seems there's some
gap.


On Wed, Aug 19, 2020 at 1:15 PM David Capwell  wrote:

> My statement was more coming from the fact that if we test on java 8 and
> find an issue it is a release blocker, so saying java 11 should be treated
> with the same regard as java 8 when it comes to filing/fixing issues; when
> it comes to filing and fixing issues, we shouldn't have different stances
> on different JVMs.  I don't want us to say "java 11 is experimental, so
> lets ignore issue X", we will have a hard time getting out of
> experimental if we have this stance.
>
> Now, don't get me wrong.  If something is very specific to java 11 and we
> can reason that the impact to users is near zero, I am fine not marking the
> issue as a release blocker.  An example is that jvm dtests crash the JVM
> because of a race condition with CMS and class unloading, this issue
> shouldn't block the release but we should still find a way to make it
> stable (changed flags when running tests on java 11 to avoid the issue).
>
> With regard to #2, we have a ways to go to get CI on-par but there is
> traction already on both fronts.  I run the java (not python) suite on java
> 11 frequently and see that known flaky tests are still flaky on java 11,
> though the suite tends to pass with enough retries.
>
>
> On Wed, Aug 19, 2020 at 9:51 AM Joshua McKenzie 
> wrote:
>
> > >
> > > 3) during 4.0 qualification, issues found on jdk 11 should block the
> > > release
> >
> > Maybe we let 2 run and see how many issues there are before we call
> release
> > blocking?
> >
> >
> >
> > On Tue, Aug 18, 2020 at 10:05 PM David Capwell 
> wrote:
> >
> > > I would propose the following:
> > >
> > > 1) leave jdk 11 marked as experimental
> > > 2) make sure CI runs jdk 8 and jdk 11 for all builds (circle / jenkins)
> > > 3) during 4.0 qualification, issues found on jdk 11 should block the
> > > release
> > >
> > > This should get us in good shape to potentially be ready to flip the
> > switch
> > > in 4.1 or even 4.0.1; given that not everyone is signing up to test
> java
> > > 11, #3 might not be enough to fully mark stable.
> > >
> > > On Tue, Aug 18, 2020 at 6:10 PM Joshua McKenzie 
> > > wrote:
> > >
> > > > Where did we land on this? Don't seem to have a clear consensus from
> > > thread
> > > > discussion.
> > > >
> > > > On Mon, Jul 20, 2020 at 10:02 PM Deepak Vohra
> >  > > >
> > > > wrote:
> > > >
> > > > >  The same link was posted earlier also.
> > > > > For Java 8 and 11 the poll result is very similar.
> > > > > Java 8 =58.4%Java 11 =22.56%
> > > > >
> > > > >
> > > > > On Monday, July 20, 2020, 04:38:03 p.m. PDT, Joshua McKenzie <
> > > > > jmcken...@apache.org> wrote:
> > > > >
> > > > >  That's remarkably close to the jrebel results for 2020:
> > > > >
> > > > >
> https://www.jrebel.com/blog/2020-java-technology-report#java-version
> > > > >
> > > > >  Came across this this past weekend doing unrelated research; can't
> > > vouch
> > > > > for the accuracy / methods / etc.
> > > > >
> > > > >
> > > > > On Mon, Jul 20, 2020 at 7:32 PM Jeff Jirsa 
> wrote:
> > > > >
> > > > > > Got it, thanks for the correction.
> > > > > >
> > > > > >
> > > > > > On Mon, Jul 20, 2020 at 4:28 PM Brandon Williams <
> dri...@gmail.com
> > >
> > > > > wrote:
> > > > > >
> > > > > > > I believe you can run them on 11, but you can't build them on
> it.
> > > > > > >
> > > > > > > On Mon, Jul 20, 2020 at 6:11 PM Jeff Jirsa 
> > > wrote:
> > > > > > > >
> > > > > > > > I still dont get it, because you can't use any released
> version
> > > of
> > > > > > > > cassandra with anything other than jdk8.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Mon, Jul 20, 2020 at 2:50 PM Patrick McFadin <
> > > > pmcfa...@gmail.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Follow-up on the informal poll I did on twitter:
> > > > > > > > >
> > > > https://twitter.com/patrickmcfadin/status/1282791302065557504?s=21
> > > > > > > > >
> > > > > > > > > Offered up as data to be used as you will.
> > > > > > > > >
> > > > > > > > > 161 votes
> > > > > > > > > <= JDK8: 59%
> > > > > > > > > JDK9 or 10: 7%
> > > > > > > > > JDK11 or 12: 27%
> > > > > > > > > JDK13 or 14: 7%
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Jul 15, 2020 at 3:19 AM Robert Stupp <
> sn...@snazy.de
> > >
> > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Yea, ZGC is kinda tricky in 11.
> > > > > > > > > >
> > > > > > > > > > —
> > > > > > > > > > Robert Stupp
> > > > > > > > > > @snazy
> > > > > >

Re: Feedback request on minor JMX interface incompatibility for CASSANDRA-15937

[Jon Meredith]

Thanks for the feedback, given three +1s and no objections then I'll
move on to get it merged.

I'm satisfied with the code and David Capwell has completed his
review. If another contributor with more experience with how JMX is
used in the community could look (particularly somebody with operator
experience) that would be greatly appreciated.

On Thu, Aug 6, 2020 at 5:56 AM Benedict Elliott Smith
 wrote:
>
> +1
>
> On 06/08/2020, 10:07, "Michael Semb Wever"  wrote:
>
>
> > I think the pragmatic thing to do is fix it now, and I'd strongly
> > prefer to do that but wanted to check if there are any objections or
> > things I hadn't considered?
>
>
> +1
>
> Thanks for giving this visibility and demonstrating we are serious about 
> the beta test cycle.
>
> -
> 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: [DISCUSS] Revisiting Java 11's experimental status

[David Capwell]

>
> s/ignore/defer until after 4.0 GA/g (semantic difference that may not sway
> you)


Even if it is experimental,  I feel that it would be best for users if we
treat java 11 bug reports the same as java 8 bug reports; it would be a bad
user experience if a user found out we knew about an issue but wanted to
ignore it in favor of releasing.

If we block the release on JDK11 issues we find, it *seems* to me that
> that's the same as saying "JDK11 is supported"


To me there is a big difference.  If users report bugs that only happen on
JDK11 then we should treat those as normal bugs found while testing the
release.  This stance does not mean that java 11 testing is on-par with our
java 8 testing, it only means we treat reports of issues equality
regardless of JDK version.

stance on found defects for JDK8 as we have for JDK11


Yep, that is what I am asking for, we should have the same stance on found
defects for JDK 8 and JDK 11.

What in my mental model here ^ doesn't match yours? :) Seems there's some
> gap.


I believe I understand your last comment as "I am ok treating bug reports
on JDK11 the same way as JDK8", if so then we are on the same page.  The
other comments about deferring would imply we have a different stance than
we do for JDK8; which I feel is the main gap?

On Wed, Aug 19, 2020 at 1:53 PM Joshua McKenzie 
wrote:

> >
> > java 11 is experimental, so lets ignore issue X
>
> s/ignore/defer until after 4.0 GA/g (semantic difference that may not sway
> you)
>
> If we block the release on JDK11 issues we find, it *seems* to me that
> that's the same as saying "JDK11 is supported" assuming we have the same a)
> level of testing and b) stance on found defects for JDK8 as we have for
> JDK11. Which I'm totally fine with fwiw.
>
> What in my mental model here ^ doesn't match yours? :) Seems there's some
> gap.
>
>
> On Wed, Aug 19, 2020 at 1:15 PM David Capwell  wrote:
>
> > My statement was more coming from the fact that if we test on java 8 and
> > find an issue it is a release blocker, so saying java 11 should be
> treated
> > with the same regard as java 8 when it comes to filing/fixing issues;
> when
> > it comes to filing and fixing issues, we shouldn't have different stances
> > on different JVMs.  I don't want us to say "java 11 is experimental, so
> > lets ignore issue X", we will have a hard time getting out of
> > experimental if we have this stance.
> >
> > Now, don't get me wrong.  If something is very specific to java 11 and we
> > can reason that the impact to users is near zero, I am fine not marking
> the
> > issue as a release blocker.  An example is that jvm dtests crash the JVM
> > because of a race condition with CMS and class unloading, this issue
> > shouldn't block the release but we should still find a way to make it
> > stable (changed flags when running tests on java 11 to avoid the issue).
> >
> > With regard to #2, we have a ways to go to get CI on-par but there is
> > traction already on both fronts.  I run the java (not python) suite on
> java
> > 11 frequently and see that known flaky tests are still flaky on java 11,
> > though the suite tends to pass with enough retries.
> >
> >
> > On Wed, Aug 19, 2020 at 9:51 AM Joshua McKenzie 
> > wrote:
> >
> > > >
> > > > 3) during 4.0 qualification, issues found on jdk 11 should block the
> > > > release
> > >
> > > Maybe we let 2 run and see how many issues there are before we call
> > release
> > > blocking?
> > >
> > >
> > >
> > > On Tue, Aug 18, 2020 at 10:05 PM David Capwell 
> > wrote:
> > >
> > > > I would propose the following:
> > > >
> > > > 1) leave jdk 11 marked as experimental
> > > > 2) make sure CI runs jdk 8 and jdk 11 for all builds (circle /
> jenkins)
> > > > 3) during 4.0 qualification, issues found on jdk 11 should block the
> > > > release
> > > >
> > > > This should get us in good shape to potentially be ready to flip the
> > > switch
> > > > in 4.1 or even 4.0.1; given that not everyone is signing up to test
> > java
> > > > 11, #3 might not be enough to fully mark stable.
> > > >
> > > > On Tue, Aug 18, 2020 at 6:10 PM Joshua McKenzie <
> jmcken...@apache.org>
> > > > wrote:
> > > >
> > > > > Where did we land on this? Don't seem to have a clear consensus
> from
> > > > thread
> > > > > discussion.
> > > > >
> > > > > On Mon, Jul 20, 2020 at 10:02 PM Deepak Vohra
> > >  > > > >
> > > > > wrote:
> > > > >
> > > > > >  The same link was posted earlier also.
> > > > > > For Java 8 and 11 the poll result is very similar.
> > > > > > Java 8 =58.4%Java 11 =22.56%
> > > > > >
> > > > > >
> > > > > > On Monday, July 20, 2020, 04:38:03 p.m. PDT, Joshua McKenzie
> <
> > > > > > jmcken...@apache.org> wrote:
> > > > > >
> > > > > >  That's remarkably close to the jrebel results for 2020:
> > > > > >
> > > > > >
> > https://www.jrebel.com/blog/2020-java-technology-report#java-version
> > > > > >
> > > > > >  Came across this this past weekend doing unrelated research;
> can't
> > > > vouch
> > > > > > for t

Re: Committing `CASSANDRA-13701 Lower default num_tokens` and the dtest slowdown…

[Anthony Grasso]

Hi Mick,

No objections from me. It will be good to get this change into the 4.0
release.

Whilst the slow down of the dtests is annoying, I am happy to see this
change committed. As long as there are no regressions in the number of
tests that pass then it should be fine. The proposal to raise a follow up
ticket to accompany the commit is a good idea.

Regards,
Anthony

On Thu, 20 Aug 2020 at 02:49, Mick Semb Wever  wrote:

> It was agreed¹ that 4.0 should have the new configuration defaults of
>   num_tokens: 16
>   allocate_tokens_for_local_replication_factor: 3
>
> 13701's patches: against cassandra, cassandra-builds, cassandra-dtest, ccm;
> are reviewed, tested, and ready to commit. But the ccm and dtest patches
> required ccm having to now start nodes sequentially, and adding some longer
> timeout values in the dtests.
>
> The consequence of this is CI runs now take longer. ci-cassandra.a.o's
> dtests take ~30% longer, and circleci's dtests (with vnodes) have gone from
> ~22 to ~43 minutes. The general opinion (on slack²) is to commit, and work
> on improving ccm and dtest startup times in a subsequent ticket.
>
> 13701 was intended to be committed before the first beta release because of
> its user-facing changes. But these numbers are significant enough it makes
> sense to touch base with dev@
>
> Does anyone (strongly) object to the "commit + follow up ticket" approach?
>
> regards,
> Mick
>
>
> ¹ –
>
> https://lists.apache.org/thread.html/ra829084fcf344e9e96fa5c61cb31e909c8629091993471594b65ea89%40%3Cdev.cassandra.apache.org%3E
> ² – https://the-asf.slack.com/archives/CK23JSY2K/p1597747395032600 and
>
> https://the-asf.slack.com/archives/CK23JSY2K/p1597849774078200?thread_ts=1597762085.048300&cid=CK23JSY2K
>

Re: [DISCUSS] Revisiting Java 11's experimental status

[J. D. Jordan]

This makes sense to me. A bug is a bug regardless of the JVM that exposes it.

Java 11 still considered experimental.  Users should understand they are on the 
less trodden path when using it.

-Jeremiah

> On Aug 19, 2020, at 7:36 PM, David Capwell  wrote:
> 

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

Re: [DISCUSS] Revisiting Java 11's experimental status

[Joshua McKenzie]

>
> This stance does not mean that java 11 testing is on-par with our
> java 8 testing, it only means we treat reports of issues equality
> regardless of JDK version.

Outside our automated testing suites, what other testing as a project
community do we consider necessary to dub something "supported"?


On Wed, Aug 19, 2020 at 9:51 PM J. D. Jordan 
wrote:

> This makes sense to me. A bug is a bug regardless of the JVM that exposes
> it.
>
> Java 11 still considered experimental.  Users should understand they are
> on the less trodden path when using it.
>
> -Jeremiah
>
> > On Aug 19, 2020, at 7:36 PM, David Capwell  wrote:
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSS] Revisiting Java 11's experimental status

[joshua . mckenzie]

Should clarify - not saying automated tests are enough. Thinking we should 
articulate better what supported means (all tools work, etc - manually checking 
the swath of stuff that’s lacking automated testing assuming we even have a 
good idea of that scope).

If we’re committing to all automated suites work on 11 and we’ll block 4.0 on 
bugs we find in jdk11, I think we should do the last small pct of work to 
formally support it. 

> On Aug 19, 2020, at 11:18 PM, Joshua McKenzie  wrote:
> 

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