Interesting enough, the author of JCtools is also a committer at LMAX: https://github.com/LMAX-Exchange/disruptor/commits/master/src/main/java/com/lmax/disruptor/RingBuffer.java?author=nitsanw
On Mon, Jan 25, 2016 at 10:59 PM, Gary Gregory <[email protected]> wrote: > Guido, > > Make sure you test/develop with Git master (which should depend on the > latest LMAX D 3.3.4) > > Gary > > On Mon, Jan 25, 2016 at 2:50 PM, Guido Medina <[email protected]> wrote: > >> @Gary >> >> I will checkout log4j2 and try to build a version with JCtools as >> dependency and run some benchmarks, plug-able? maybe is not worth the >> effort as the user would have to somehow specify which implementation will >> use, and changing the whole thing from LMAX to JCtools will require changes >> on the documentation which isn't ideas TBH, let me first try and benchmark >> and then we can discuss more. >> >> @Remko, >> >> Mpsc = Multiple Producer - Single Consumer >> >> MpscLinkedQueue is the unbounded version which isn't exactly the >> counterpart of LMAX, in that case it would be MpscArrayQueue which is a >> circular buffer (same as LMAX) with the lock free algorithm of Lamport, >> JCTools is just one proper implementation I have found of *Lamport *which >> as JCtools states it is used at RxJava, Netty and Akka >> >> I spelled Lamport wrongly in the subject my bad. >> >> To be honest I didn't research much, I had issues specifically with my >> akka LMAX mailbox implementation, Java 8 and akka dispatchers which are >> mostly fork-join executors. >> >> I found JCtools less confusing than LMAX and more a straight forward Java >> Queue implementation, LMAX I have only heard good things about it but >> unfortunately for my project in Akka, Java 8 and Debian 7, 8 wasn't working >> as it should, maybe I need to research more. >> >> Regards, >> >> Guido. >> >> On Mon, Jan 25, 2016 at 10:19 PM, Remko Popma <[email protected]> >> wrote: >> >>> Guido, >>> >>> Interesting. Can you provide more detail on the CPU problem you were >>> seeing and the environment it happened in? >>> Also interested to hear more about your research and why you concluded >>> that MpscLinkedQueue is preferable to the LMAX Disruptor for >>> inter-thread communication. >>> >>> Remko >>> >>> >>> On Tue, Jan 26, 2016 at 7:03 AM, Gary Gregory <[email protected]> >>> wrote: >>> >>>> Hi Guido, >>>> >>>> This is not on our radar AFAIK. >>>> >>>> Your best bet would be to create a patch that makes that part of the >>>> code pluggable with LMAX vs. Lampart, and then add to the benchmark module >>>> to show the difference. >>>> >>>> This is not a trivial task. >>>> >>>> What we could discuss though is whether it is worth it for Log4j itself >>>> to make this pluggable, in which case you contribution would be very >>>> helpful! >>>> >>>> Cheers, >>>> Gary >>>> On Jan 25, 2016 9:00 AM, "Guido Medina" <[email protected]> wrote: >>>> >>>>> I'm wondering if anyone would be willing to test the current LMAX >>>>> implementation vs JCTools specifically using the following class: >>>>> >>>>> I currently use them with Akka mailboxes, I tried LMAX once but with >>>>> some CPUs LMAX disruptor was behaving a bit weird which is why I prefer >>>>> Lamport's implementations of circular buffers that are very well known and >>>>> in use by Netty, Akka, etc. >>>>> >>>>> Or I could try and contribute by changing the LMAX for JCTools: >>>>> >>>>> JCtools-core dependency: >>>>> >>>>> <dependency> >>>>> <groupId>org.jctools</groupId> >>>>> <artifactId>jctools-core</artifactId> >>>>> <version>1.1</version> >>>>> </dependency> >>>>> >>>>> Specific class that would replace LMAX disruptor: >>>>> https://github.com/JCTools/JCTools/blob/master/jctools-core/src/main/java/org/jctools/queues/MpscArrayQueue.java >>>>> >>>>> Best regards, >>>>> >>>>> Guido. >>>>> >>>> >>> >> > > > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second Edition > <http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory >
