Re: Java 11 Z garbage collector

[Carl Mueller]

Oh nice, I'll check that out.

On Thu, Aug 30, 2018 at 11:07 AM Jonathan Haddad  wrote:

> Advertised, yes, but so far I haven't found it to be any better than
> ParNew + CMS or G1 in the performance tests I did when writing
> http://thelastpickle.com/blog/2018/08/16/java11.html.
>
> That said, I didn't try it with a huge heap (i think it was 16 or 24GB), so
> maybe it'll do better if I throw 50 GB RAM at it.
>
>
>
> On Thu, Aug 30, 2018 at 8:42 AM Carl Mueller
>  wrote:
>
> > https://www.opsian.com/blog/javas-new-zgc-is-very-exciting/
> >
> > .. max of 4ms for stop the world, large terabyte heaps, seems promising.
> >
> > Will this be a major boon to cassandra p99 times? Anyone know the aspects
> > of cassandra that cause the most churn and lead to StopTheWorld GC? I was
> > under the impression that bloom filters, caches, etc are statically
> > allocated at startup.
> >
>
>
> --
> Jon Haddad
> http://www.rustyrazorblade.com
> twitter: rustyrazorblade
>

Re: Java 11 Z garbage collector

[Jonathan Haddad]

Advertised, yes, but so far I haven't found it to be any better than
ParNew + CMS or G1 in the performance tests I did when writing
http://thelastpickle.com/blog/2018/08/16/java11.html.

That said, I didn't try it with a huge heap (i think it was 16 or 24GB), so
maybe it'll do better if I throw 50 GB RAM at it.



On Thu, Aug 30, 2018 at 8:42 AM Carl Mueller
 wrote:

> https://www.opsian.com/blog/javas-new-zgc-is-very-exciting/
>
> .. max of 4ms for stop the world, large terabyte heaps, seems promising.
>
> Will this be a major boon to cassandra p99 times? Anyone know the aspects
> of cassandra that cause the most churn and lead to StopTheWorld GC? I was
> under the impression that bloom filters, caches, etc are statically
> allocated at startup.
>


-- 
Jon Haddad
http://www.rustyrazorblade.com
twitter: rustyrazorblade

Java 11 Z garbage collector

[Carl Mueller]

https://www.opsian.com/blog/javas-new-zgc-is-very-exciting/

.. max of 4ms for stop the world, large terabyte heaps, seems promising.

Will this be a major boon to cassandra p99 times? Anyone know the aspects
of cassandra that cause the most churn and lead to StopTheWorld GC? I was
under the impression that bloom filters, caches, etc are statically
allocated at startup.

Re: Yet another repair solution

[Dinesh Joshi]

In the meanwhile, do you think you could highlight the features of your repair 
solution / sidecar?

Dinesh

> On Aug 30, 2018, at 4:57 AM, Marcus Olsson  wrote:
> 
> Great to see that there is an interest! As there currently are some internal 
> dependencies etc. in place there is still some work to be done before we can 
> publish it. I would expect this to take at least a few weeks, to try set the 
> correct expectations.
> 
> Best Regards
> Marcus Olsson
> 
> On tis, 2018-08-28 at 23:18 -0700, Vinay Chella wrote:
> I am excited to see that the community is working on solving the critical
> problems in C* operations (e.g., repair, backups etc.,) with different
> solutions. Of course, learnings from these systems are key to designing the
> robust solution which works for everyone.
> 
> 
> Thanks,
> Vinay Chella
> 
> 
> On Tue, Aug 28, 2018 at 1:23 PM Roopa 
> mailto:rtangir...@netflix.com.invalid>>
> wrote:
> 
> 
> +1 interested in seeing and understanding another repair solution.
> 
> 
> On Aug 28, 2018, at 1:03 PM, Joseph Lynch 
> mailto:joe.e.ly...@gmail.com>> wrote:
> 
> I'm pretty interested in seeing and understanding your solution! When we
> started on CASSANDRA-14346 reading your design documents and plan you
> sketched out in CASSANDRA-10070 were really helpful in improving our
> design. I'm particularly interested in how the Scheduler/Job/Task APIs
> turned out (we're working on something similar internally and would love
> to
> 
> compare notes and figure out the best way to implement that kind of
> abstraction)?
> 
> -Joey
> 
> 
> On Tue, Aug 28, 2018 at 6:34 AM Marcus Olsson <
> marcus.ols...@ericsson.com>
> 
> wrote:
> 
> 
> Hi,
> 
> With the risk of stirring the repair/side-car topic  even further I'd
> just
> 
> 
> like to mention that we have recently gotten approval to contribute our
> repair management side-car solution.
> It's based on the proposal in
> https://issues.apache.org/jira/browse/CASSANDRA-10070 as a standalone
> application sitting next to each instance.
> With the recent discussions in mind I'd just like to hear the thoughts
> from the community on this before we put in the effort of bringing our
> solution into open source.
> 
> Would there be an interest of having yet another repair solution in the
> discussion?
> 
> Best Regards
> Marcus Olsson
> 
> -
> 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: Yet another repair solution

[Marcus Olsson]

Great to see that there is an interest! As there currently are some internal 
dependencies etc. in place there is still some work to be done before we can 
publish it. I would expect this to take at least a few weeks, to try set the 
correct expectations.

Best Regards
Marcus Olsson

On tis, 2018-08-28 at 23:18 -0700, Vinay Chella wrote:
I am excited to see that the community is working on solving the critical
problems in C* operations (e.g., repair, backups etc.,) with different
solutions. Of course, learnings from these systems are key to designing the
robust solution which works for everyone.


Thanks,
Vinay Chella


On Tue, Aug 28, 2018 at 1:23 PM Roopa 
mailto:rtangir...@netflix.com.invalid>>
wrote:


+1 interested in seeing and understanding another repair solution.


On Aug 28, 2018, at 1:03 PM, Joseph Lynch 
mailto:joe.e.ly...@gmail.com>> wrote:

I'm pretty interested in seeing and understanding your solution! When we
started on CASSANDRA-14346 reading your design documents and plan you
sketched out in CASSANDRA-10070 were really helpful in improving our
design. I'm particularly interested in how the Scheduler/Job/Task APIs
turned out (we're working on something similar internally and would love
to

compare notes and figure out the best way to implement that kind of
abstraction)?

-Joey


On Tue, Aug 28, 2018 at 6:34 AM Marcus Olsson <
marcus.ols...@ericsson.com>

wrote:


Hi,

With the risk of stirring the repair/side-car topic  even further I'd
just


like to mention that we have recently gotten approval to contribute our
repair management side-car solution.
It's based on the proposal in
https://issues.apache.org/jira/browse/CASSANDRA-10070 as a standalone
application sitting next to each instance.
With the recent discussions in mind I'd just like to hear the thoughts
from the community on this before we put in the effort of bringing our
solution into open source.

Would there be an interest of having yet another repair solution in the
discussion?

Best Regards
Marcus Olsson

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

Re: Supporting multiple JDKs

[Mick Semb Wever]

Hey Sumanth,
 could you clear a few things up for me…

> C* 2.2

> > I'm still a bit confused as to what's the benefit in compiling with
> > jdk1.7 and then testing with jdk1.7 or jdk1.8
>
> I meant two separate workflows for each JDK i.e.
> Workflow1: Build against jdk1.7, and optionally run UTs and Dtests against
> 1.7

I'm still left wondering why we want to use CI resources to find bugs that the 
users will never encounter.
If you take out "and optionally run UTs and Dtests against 1.7" from workflow1 
then I'm fine with it.

The time it takes for tests to run is a headache, so to have to run dtests four 
times over makes me grimace.


> C* 4.0

I'm not quite clear on what the change you intend here is.

Currently afaik we can't build the artefacts against only either JDK8 or JDK11, 
hence the hybrid jdk setup.
I think building the artefacts should be part of the CI build step because 
patches are not always about java code. 

And that unit and dtests are run only against these 'release' built artefacts. 
Presuming the plan remains that the hybrid approach would be the 'release' 
process so long as jdk11 was GA before Cassandra-4.0.

https://lists.apache.org/thread.html/45b3f12885f881d211f79368bdd5046e504e0149757cf19c8747bcb2@%3Cdev.cassandra.apache.org%3E

In that thread it was mentioned the concerns about the cost of running tests 
twice, and whether we should avoid running tests with JDK11 until we're closer 
to formally supporting JDK11 at run-time. 

regards,
Mick

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

Re: TTL of paxos table

[kurt greaves]

It's just that compaction hasn't occured. TTL works even though GCGS is 0.
There's been multiple discussions around this in the past, but we haven't
come to a consensus yet though. Some proposals to change compaction
strategy, some want to make it customisable. Treating paxos as sub-tables
has also come up and the improvements listed in CASSANDRA-13548.
TBH we should probably do 13548 and see where that gets us.

On 30 August 2018 at 13:14, Yuji Ito  wrote:

> Hi,
>
> I wonder why records on the system.paxos table aren't removed, though all
> records are updated with TTL (at least 3 hours).
> That's because gc_grace_seconds of system.paxos table is always 0 and users
> can't change that value of System keyspace!
>
> Why is the TTL of paxos record invalidated?
> Or, I'm misunderstanding?
>
> Related to:
> https://issues.apache.org/jira/browse/CASSANDRA-5451
> https://issues.apache.org/jira/browse/CASSANDRA-13548
>
> Thanks,
> Yuji
>