Re: Supporting multiple JDKs
What do we mean "support multiple JDKs" ? Are we talking Run-time or Compile-time? > If we support multiple JDKs, at a minimum we should compile code against > those JDKs. Why? I really don't get that logic. There's a cost-optimisation here in reducing what we have to support. If we support compiling with multiple JDKs and running with multiple JDKs, then we've a matrix of things to test. And it's kinda odd i think, when we don't need to compile against multiple JDKs and don't distribute releases built on different JDKs. The suggestion to use the AnimalSniffer ant task was a way to simply this. That is, so we can - only build with one JDK (the same we build releases with), - run unit tests only against that JDK, - run dtests against multiple JDKs. Ensuring at compile-time that earlier JDKs are supported at run-time then is done using the AnimalSniffer ant task. It doesn't just simply the testing matrix, but provides a quick feedback loop to the developer when they accidentally code against a java api that's not available in the older JDK. There's also two contexts here: Cassandra-2.2 (jdks 1.7 and 1.8) and Cassandra-4.0 (jdks 1.8 and 11). I don't know if it's possible, but it would be awesome once jdk11 is released that it's the only jdk we use to compile Cassandra-4.0+ with. regards, Mick - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: JIRAs in Review
Just want to bump this up if any reviewers have time before the 9/1 window.
I think these are all patch available and ready for review at this point.
Useful improvements for 4.0:
>
> https://issues.apache.org/jira/browse/CASSANDRA-14303 and
> https://issues.apache.org/jira/browse/CASSANDRA-14557 - Makes the user
> interface for creating keyspaces easier to use and less error prone. For
> example "CREATE KEYSPACE foo WITH replication = {'class':
> 'NetworkTopologyStrategy'}" would just do the right thing after both
> patches.
>
> https://issues.apache.org/jira/browse/CASSANDRA-14459 - Limits the
> DynamicEndpointSnitch's use of latent replicas. This should help with slow
> queries on startup and every 10 minutes during DES reset (when the snitch's
> latency data is empty). There is also a riskier potential follow up patch
> which improves the performance of the latency tracking mechanism by ~10x
> and reduces garbage to near zero. I believe that Jason is looking at this.
>
> https://issues.apache.org/jira/browse/CASSANDRA-14297 - Improves the
> startup check functionality to make it so that operators can be more
> confident that they won't throw unavailable or timeouts during node
> restarts. The patch has merge conflicts right now but I was waiting on
> someone to confirm it's worth doing before I spend more time on it.
>
> Minor cleanup patches:
> https://issues.apache.org/jira/browse/CASSANDRA-9452 - Cleanup of some
> old configuration, probably an easy thing to commit.
>
Since then we have a few more:
https://issues.apache.org/jira/browse/CASSANDRA-14358 - Improves the
handling of network partitions, especially those caused by statefull
firewalls (e.g. AWS security groups)
https://issues.apache.org/jira/browse/CASSANDRA-14319 - Doesn't let
nodetool rebuild pass invalid datacenters
Cheers,
-Joey
Re: Supporting multiple JDKs
I think we should have the ability to build & run unit tests and dtests against a specified JDK. If we support multiple JDKs, at a minimum we should compile code against those JDKs. It would be ideal if we could run unit tests and dtests but given the availability of CircleCI resources that could be time consuming. Dinesh On Wednesday, August 22, 2018, 10:12:35 AM PDT, Sumanth Pasupuleti wrote: Hi, The goal of this email is to arrive at a solution (probably resulting in a few follow-ups) to ensure support for multiple JDKs for different versions of Cassandra. This comes out of Jason's comment in https://issues.apache.org/jira/browse/CASSANDRA-14563. Below is the proposal. Please provide your thoughts. C* 2.2 Goal: Need to support Java7 and Java8. Current State: CircleCI workflow to build, run UTs and DTests against Java8 (run by default) Proposed State: * Add CircleCI workflow to build against Java7 ( https://issues.apache.org/jira/browse/CASSANDRA-14625), and optionally run UTs and DTests against Java7 * Add a tool like AnimalSniffer into build process (proposed by Mick in https://issues.apache.org/jira/browse/CASSANDRA-14563), so that build would fail as part of the development process in case of JDK incompatibility. C* 3.0 and 3.11 Goal: Support Java8. Current state: CircleCI workflow to build, run UTs and DTests against Java8 (run by default) Proposed State: * No change. Same as current. C* 4.0 Goal: Support Java8 and Java11. Current state: CircleCI workflow to build, run UTs and DTests against Java8 (run by default) Proposed State: * Add CircleCI workflow to build against Java11, and optionally run UTs and DTests against Java11 Looking forward to any feedback. Thanks, Sumanth
Supporting multiple JDKs
Hi, The goal of this email is to arrive at a solution (probably resulting in a few follow-ups) to ensure support for multiple JDKs for different versions of Cassandra. This comes out of Jason's comment in https://issues.apache.org/jira/browse/CASSANDRA-14563. Below is the proposal. Please provide your thoughts. C* 2.2 Goal: Need to support Java7 and Java8. Current State: CircleCI workflow to build, run UTs and DTests against Java8 (run by default) Proposed State: * Add CircleCI workflow to build against Java7 ( https://issues.apache.org/jira/browse/CASSANDRA-14625), and optionally run UTs and DTests against Java7 * Add a tool like AnimalSniffer into build process (proposed by Mick in https://issues.apache.org/jira/browse/CASSANDRA-14563), so that build would fail as part of the development process in case of JDK incompatibility. C* 3.0 and 3.11 Goal: Support Java8. Current state: CircleCI workflow to build, run UTs and DTests against Java8 (run by default) Proposed State: * No change. Same as current. C* 4.0 Goal: Support Java8 and Java11. Current state: CircleCI workflow to build, run UTs and DTests against Java8 (run by default) Proposed State: * Add CircleCI workflow to build against Java11, and optionally run UTs and DTests against Java11 Looking forward to any feedback. Thanks, Sumanth
Re: JIRAs in Review
Hi, Hopefully it's not too late to add to this list. https://issues.apache.org/jira/browse/CASSANDRA-14096 could use some reviewing. This issue occurs if you have multiple tables in a keyspace and perform a full repair. Then you could end up storing alot of MerkleTrees in memory until the repair is completed. The applied patch is for 3.0.x, but before creating patches for 4.0 I thought it might be best to agree on the way forward (two solution proposals have been provided). Best Regards Marcus Olsson On fre, 2018-07-20 at 15:42 +1000, kurt greaves wrote: > Cheers Dinesh, not too worried about that one in 4.0's case though as > it's > a bug but it will need a committer. > > As for improvements for 4.0: > https://issues.apache.org/jira/browse/CASSANDRA-13010 - More verbose > nodetool compactionstats. Speaks for itself. > https://issues.apache.org/jira/browse/CASSANDRA-10023 - Metrics for > number > of local reads/writes. For detecting when you're choosing wrong > coordinators. Useful for those of us without access to clients. > https://issues.apache.org/jira/browse/CASSANDRA-10789 - nodetool > blacklist > command to stop bad clients. Would be great for the sysadmin toolbox. > > https://issues.apache.org/jira/browse/CASSANDRA-13841 - Smarter > nodetool > rebuild. Kind of a bug but would be nice to get it in 4.0 *at least*. > (I > probably need to rebase this) > https://issues.apache.org/jira/browse/CASSANDRA-14309 - Hint window > persistence. Would be nice to get some thoughts on this. > https://issues.apache.org/jira/browse/CASSANDRA-12783 - Batchlog > refactor > to better support MV's. Been meaning to get back to this one, but > it's > pretty much there except needs rebase and a bit more testing. Someone > else > to go over it and see if it makes sense would be useful. > > May have traction? but worth keeping an eye on. > https://issues.apache.org/jira/browse/CASSANDRA-14291 - Nodetool > command to > regenerate SSTable components. Mostly important for efficient > summary/bloomfilter regeneration which doesn't exist apart from using > upgradesstables. Other than that it's effectively upgradesstables but > with > a cleaner interface. Chris has started looking at this but would > probably > be nice to make sure it gets in before 4.0 seeing as we have no way > to > regenerate bloomfilter/summary without re-writing the entire SSTable > ATM. > > Other than that hoping to get > https://issues.apache.org/jira/browse/CASSANDRA-10540 (RangeAwareCS) > in. On > Markus' plate ATM but I'm fairly sure its been decently reviewed. > > On 19 July 2018 at 10:07, dinesh.jo...@yahoo.com.INVALID < > dinesh.jo...@yahoo.com.invalid> wrote: > > > > > Kurt was looking at some help with this ticket - > > https://issues.apache.org/jira/browse/CASSANDRA-14525 > > Dinesh > > > > On Tuesday, July 17, 2018, 12:35:25 PM PDT, sankalp kohli < > > kohlisank...@gmail.com> wrote: > > > > Hi, > > We are 7 weeks away from 4.0 freeze and there are ~150 JIRAs > > waiting > > for review. It is hard to know which ones should be prioritized as > > some of > > them could be not valid(fixes 2.0 bug), some of them will have the > > assignee > > who no longer is active, etc. > > > > If anyone is *not* getting traction on the JIRA to get it reviewed, > > please > > use this thread to send your JIRA number and optionally why it is > > important. > > > > Thanks, > > Sankalp > > > > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
