I didn't even know there are plans to move to TPC in Cs. Thanks for that update. After all I will follow the development of both Scylla and Cs and am excited about the future of both!
Am 27.11.2016 10:02 schrieb "Kant Kodali" <k...@peernova.com>: > Yes I am well aware of Scyalldb. It might be well written in C++ but the > performance gain they are claiming has very little to do with moving from > Java to C++. They had major design changes such as moving away from SEDA to > TPC and so on. Moreover I would say it still needs to mature. Lot of users > had complained that they cannot get the benchmarks similar to the ones that > are posted online and I keep seeing comments stating that you need to use a > specific hardware and specific tuning mechanisms and so on (I don't mean to > say what scylladb is claiming is wrong I certainly haven't verified it but > I do know for the fact lot of people are having trouble to reach those > benchmarks). > > SEDA to TPC is a very big change. Let's see how long it would take for > Apache C* > > https://issues.apache.org/jira/browse/CASSANDRA-10989 > > > > > On Sat, Nov 26, 2016 at 11:45 PM, Benjamin Roth <benjamin.r...@jaumo.com> > wrote: > >> You are of course right. There is no solution and no language that is a >> perfect match for every situation and every solution and language has it's >> own pros, cons, pitfalls and drawbacks. >> Actually that article you posted points at some aspect of ARC, I wasn't >> aware of, yet. >> Nevertheless, GC is an issue for Cassandra, otherwise this thread would >> not exist, right? But we have to deal with it and get the best out of it. >> >> Another option, besides optimizing your GC: You could check if >> http://www.scylladb.com/ is an option for you. >> They rewrote CS from the scratch. The goal is to be completely compatible >> with CS but to be much, much faster. Check their benchmarks and their >> architecture. >> I really do not want do depreciate the work of all the Cassandra >> Developers - they did a great job - but what I have seen there looked very >> interesting and promising! By the way it's written in C++. >> >> >> 2016-11-27 7:06 GMT+01:00 Kant Kodali <k...@peernova.com>: >> >>> Automatic Reference counting sounds like college level idea that we all >>> have been hearing for since GC is born! There seem to be bunch of cons of >>> ARC as explained here >>> >>> https://www.quora.com/Why-doesnt-Apple-Swift-adopt-the-memor >>> y-management-method-of-garbage-collection-like-in-Java >>> >>> Maintaining C and C++ APPS are never a pain? How about versioning and >>> static time libraries? There is work there too. so its all pros and cons >>> >>> "gc is a pain in the ass". How about seg faults? they aren't any lesser >>> pain :) >>> >>> Not only Cassandra that runs on JVM. Majority of Apache projects do run >>> on JVM for a reason. >>> >>> Bottom line. My point here is there are pros and cons of every language. >>> It doesn't make much sense to target one language. >>> >>> >>> >>> >>> >>> >>> On Sat, Nov 26, 2016 at 9:31 PM, Benjamin Roth <benjamin.r...@jaumo.com> >>> wrote: >>> >>>> Arc means Automatic Reference counting which is done at compilen time. >>>> Eg Objektive c and Swift use this technique. There are absolutely No gc's. >>>> Its a completely different memory Management technique. >>>> >>>> Why i dont like Java on Server side? Because gc is a pain in the ass. I >>>> am doing this Business since over 15 years and running/maintaining Apps >>>> that are build in c or c++ has never been such a pain. >>>> >>>> On the other Hand Java is easier to handle for Developers. And coding >>>> plain c is also a pain. >>>> >>>> Thats why i Said its a philosophic discussion. >>>> Anyway Cassandra rund on Java so We have to Deal with it. >>>> >>>> Am 27.11.2016 05:28 schrieb "Kant Kodali" <k...@peernova.com>: >>>> >>>>> Benjamin Roth: How do you know Arc eliminates GC pauses completely? By >>>>> completely I mean no GC pauses whatsoever. >>>>> >>>>> When you say Java is NOT the First choice for Server Applications you >>>>> are generalizing it too much I would say since many of them fall under >>>>> that >>>>> category. Either way the statement you made is purely subjective. >>>>> >>>>> On Fri, Nov 25, 2016 at 2:41 PM, Benjamin Roth < >>>>> benjamin.r...@jaumo.com> wrote: >>>>> >>>>>> Lol. The counter proof is to use another memory Model like Arc. Thats >>>>>> why i personally think Java is NOT the First choice for Server >>>>>> Applications. But thats a philosophic discussion. >>>>>> >>>>>> Am 25.11.2016 23:38 schrieb "Kant Kodali" <k...@peernova.com>: >>>>>> >>>>>>> +1 Chris Lohfink response >>>>>>> >>>>>>> I would also restate the following sentence "java GC pauses are >>>>>>> pretty much a fact of life" to "Any GC based system pauses are >>>>>>> pretty much a fact of life". >>>>>>> >>>>>>> I would be more than happy to see if someone can counter prove. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Nov 25, 2016 at 1:41 PM, Chris Lohfink <clohfin...@gmail.com >>>>>>> > wrote: >>>>>>> >>>>>>>> No tuning will eliminate gcs. >>>>>>>> >>>>>>>> 20-30 seconds is horrific and out of the ordinary. Most likely >>>>>>>> implementing antipatterns and/or poorly configured. Sub 1s is >>>>>>>> realistic but >>>>>>>> with some workloads still may require some tuning to maintain. Some >>>>>>>> workloads are very unfriendly to GCs though (ie heavy tombstones, very >>>>>>>> wide >>>>>>>> partitions). >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> On Fri, Nov 25, 2016 at 3:25 PM, S Ahmed <sahmed1...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hello! >>>>>>>>> >>>>>>>>> From what I understand java GC pauses are pretty much a fact of >>>>>>>>> life, but you can tune the jvm to reduce the likelihood of the >>>>>>>>> frequency >>>>>>>>> and length of GC pauses. >>>>>>>>> >>>>>>>>> When using Cassandra, how frequent or long have these pauses known >>>>>>>>> to be? Even with tuning, is it safe to assume they cannot be >>>>>>>>> eliminated? >>>>>>>>> >>>>>>>>> Would a 20-30 second pause be something out of the ordinary? >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> >> >> >> -- >> Benjamin Roth >> Prokurist >> >> Jaumo GmbH · www.jaumo.com >> Wehrstraße 46 · 73035 Göppingen · Germany >> Phone +49 7161 304880-6 · Fax +49 7161 304880-1 >> AG Ulm · HRB 731058 · Managing Director: Jens Kammerer >> > >
