@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. >>> >> >
