@Sampath We can drop the subject because it won't be practical for Log4j2 to move to another implementation.
Now from an academic perspective both implementations are different, you might want to read the following article: http://natsys-lab.blogspot.ie/2014/01/natsys-lock-free-queue-in-comparison.html It is explained there why some algorithms prefer CAS vs Yield/Wait logics, also JCTools now that I think about is not usable for Log4j2 as it is non-blocking, meaning that a bounded queue will return *false* if you *offer(...)* and the queue is full but; that's exactly what I wanted for my project: *A bounded non-blocking lock free queue.* Now JCtools will release more queues but at the moment they are under the experimental sub-project, one of them that call my attention is the *GrowableArrayQueue* which has min/max capacity, can get ideas for that: https://github.com/JCTools/JCTools/tree/master/jctools-experimental/src/main/java/org/jctools/queues Regards, Guido. On Wed, Jan 27, 2016 at 4:31 AM, sampath kumar <[email protected]> wrote: > @Guido, > > I just have quick look at the implementation of *MpscArrayQueue *methods > *offer,poll*. Don't you think below block keep the CPU in busy state ? I > see mainly WaitingStrategy are missing in MpscArrayQueue *,*and also i > see lot of features like event notification, pattern like chine of > responsibility missing in JCTools,Please correct me if I miss any thing > here ? > > final long mask = this.mask; > final long capacity = mask + 1; > long consumerIndexCache = lvConsumerIndexCache(); // LoadLoad > long currentProducerIndex; > * do {* > currentProducerIndex = lvProducerIndex(); // LoadLoad > final long wrapPoint = currentProducerIndex - capacity; > if (consumerIndexCache <= wrapPoint) { > final long currHead = lvConsumerIndex(); // LoadLoad > if (currHead <= wrapPoint) { > return false; // FULL :( > } else { > // update shared cached value of the consumerIndex > svConsumerIndexCache(currHead); // StoreLoad > // update on stack copy, we might need this value > again if we lose the CAS. > consumerIndexCache = currHead; > } > } > * } while (!casProducerIndex(currentProducerIndex, > currentProducerIndex + 1));* > > > public E poll() { > final long consumerIndex = lpConsumerIndex(); > final long offset = calcElementOffset(consumerIndex); > // Copy field to avoid re-reading after volatile load > final E[] buffer = this.buffer; > // If we can't see the next available element we can't poll > E e = lvElement(buffer, offset); // LoadLoad > if (null == e) { > /* > * NOTE: Queue may not actually be empty in the case of a > producer (P1) being interrupted after > * winning the CAS on offer but before storing the element in > the queue. Other producers may go on > * to fill up the queue after this element. > */ > if (consumerIndex != lvProducerIndex()) { > *do {* > e = lvElement(buffer, offset); > * } while (e == null);* > } else { > return null; > } > } > > spElement(buffer, offset, null); > soConsumerIndex(consumerIndex + 1); // StoreStore > return e; > } > > Regards, > Sampath > > > On Wed, Jan 27, 2016 at 3:31 AM, Remko Popma <[email protected]> > wrote: > >> To be honest, there would have to be a significant performance (or other) >> advantage in using JCTools. Otherwise users would simply be exchanging one >> dependency for another, I can't see the point of that... >> >> Remko >> >> Sent from my iPhone >> >> On 2016/01/27, at 0:42, Matt Sicker <[email protected]> wrote: >> >> It would be cool to see some JMH comparisons between the two approaches. >> >> On 26 January 2016 at 06:54, Guido Medina <[email protected]> wrote: >> >>> Well, this morning I got rid of Log4j2 asynchronous config and LMAX >>> dependency which combined with akka-log4j + log4j2 RollingRandomAccessFile >>> should give me a decent performance. >>> >>> On Tue, Jan 26, 2016 at 12:51 PM, Mikael Ståldal < >>> [email protected]> wrote: >>> >>>> It would be nice if you could leverage the asynchronicity of Akka >>>> while still using the Log4j 2 API. >>>> >>>> On Tue, Jan 26, 2016 at 1:50 PM, Mikael Ståldal < >>>> [email protected]> wrote: >>>> >>>>> I guess that if you would do all logging through Akka's actor logging, >>>>> they async logging of Log4j would be unnecessary since Akka gives you the >>>>> asynchronicity. But you probably like the Log4j 2 native API better than >>>>> Akka's logging API. >>>>> >>>>> On Tue, Jan 26, 2016 at 1:44 PM, Mikael Ståldal < >>>>> [email protected]> wrote: >>>>> >>>>>> I wasn't aware of this akka-log4j. Nice, I should try it to get rid >>>>>> of SLF4J. >>>>>> >>>>>> Perhaps there should be a page with links to this and similar other >>>>>> open source projects with explicit support of Log4j 2 somewhere on the >>>>>> Log4j web site? >>>>>> >>>>>> On Tue, Jan 26, 2016 at 1:18 PM, Guido Medina <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> I have both configured, for akka internal logging I'm using >>>>>>> akka-log4j extension: >>>>>>> >>>>>>> https://github.com/hseeberger/akka-log4j >>>>>>> >>>>>>> so that akka internal logging still uses my Log4j2 config but in my >>>>>>> code I'm using *LogManager.getLogger(...)* and for other APIs that >>>>>>> rely on Slf4j I have the jar bridge to Log4j2. >>>>>>> I'm using a RollingRandomAccessFile with all asynchronous appenders >>>>>>> including root. >>>>>>> >>>>>>> On Tue, Jan 26, 2016 at 9:08 AM, Mikael Ståldal < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Are you using Log4j together with Akka? Do you use the Log4j API >>>>>>>> directly, or through Akka's actor logging framework? >>>>>>>> >>>>>>>> On Mon, Jan 25, 2016 at 6:00 PM, 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. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> [image: MagineTV] >>>>>>>> >>>>>>>> *Mikael Ståldal* >>>>>>>> Senior software developer >>>>>>>> >>>>>>>> *Magine TV* >>>>>>>> [email protected] >>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com >>>>>>>> >>>>>>>> Privileged and/or Confidential Information may be contained in this >>>>>>>> message. If you are not the addressee indicated in this message >>>>>>>> (or responsible for delivery of the message to such a person), you >>>>>>>> may not copy or deliver this message to anyone. In such case, >>>>>>>> you should destroy this message and kindly notify the sender by >>>>>>>> reply email. >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> [image: MagineTV] >>>>>> >>>>>> *Mikael Ståldal* >>>>>> Senior software developer >>>>>> >>>>>> *Magine TV* >>>>>> [email protected] >>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com >>>>>> >>>>>> Privileged and/or Confidential Information may be contained in this >>>>>> message. If you are not the addressee indicated in this message >>>>>> (or responsible for delivery of the message to such a person), you >>>>>> may not copy or deliver this message to anyone. In such case, >>>>>> you should destroy this message and kindly notify the sender by reply >>>>>> email. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> [image: MagineTV] >>>>> >>>>> *Mikael Ståldal* >>>>> Senior software developer >>>>> >>>>> *Magine TV* >>>>> [email protected] >>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com >>>>> >>>>> Privileged and/or Confidential Information may be contained in this >>>>> message. If you are not the addressee indicated in this message >>>>> (or responsible for delivery of the message to such a person), you may >>>>> not copy or deliver this message to anyone. In such case, >>>>> you should destroy this message and kindly notify the sender by reply >>>>> email. >>>>> >>>> >>>> >>>> >>>> -- >>>> [image: MagineTV] >>>> >>>> *Mikael Ståldal* >>>> Senior software developer >>>> >>>> *Magine TV* >>>> [email protected] >>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com >>>> >>>> Privileged and/or Confidential Information may be contained in this >>>> message. If you are not the addressee indicated in this message >>>> (or responsible for delivery of the message to such a person), you may >>>> not copy or deliver this message to anyone. In such case, >>>> you should destroy this message and kindly notify the sender by reply >>>> email. >>>> >>> >>> >> >> >> -- >> Matt Sicker <[email protected]> >> >> > > > -- > Regards, > Sampath >
