You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Guido Medina <ox...@gmail.com> on 2016/01/25 18:00:36 UTC
LMAX vs Lampart
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.
Re: LMAX vs Lampart
Posted by Guido Medina <ox...@gmail.com>.
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 <ga...@gmail.com>
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 <ox...@gmail.com> 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 <re...@gmail.com>
>> 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 <ga...@gmail.com>
>>> 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" <ox...@gmail.com> 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: garydgregory@gmail.com | ggregory@apache.org
> 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
>
Re: LMAX vs Lampart
Posted by Gary Gregory <ga...@gmail.com>.
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 <ox...@gmail.com> 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 <re...@gmail.com>
> 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 <ga...@gmail.com>
>> 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" <ox...@gmail.com> 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: garydgregory@gmail.com | ggregory@apache.org
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
Re: LMAX vs Lampart
Posted by Guido Medina <ox...@gmail.com>.
@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 <re...@gmail.com> 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 <ga...@gmail.com>
> 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" <ox...@gmail.com> 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.
>>>
>>
>
Re: LMAX vs Lampart
Posted by Remko Popma <re...@gmail.com>.
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 <ga...@gmail.com>
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" <ox...@gmail.com> 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.
>>
>
Re: LMAX vs Lampart
Posted by Gary Gregory <ga...@gmail.com>.
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" <ox...@gmail.com> 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.
>
Re: LMAX vs Lampart
Posted by Guido Medina <ox...@gmail.com>.
I didn't TBH, I only used YieldWaitStrategy, here is the original source I
tried for Akka:
https://github.com/guidomedina/akka-disruptor/blob/master/src/main/java/akka/dispatch/SingleConsumerOnlyBoundedMessageQueue.java
But ... I ended up concluding that LMAX is ok for inter-thread comms but a
lock free queue is better for that, as a queue hence I switched to JCTools
which isn't more than a proper Lamport's algorithm with some modifications
which its model has been copied to Netty and Akka, for example the fastest
Akka mailbox which is SingleConsumerOnlyMailbox is based on
MpscLinkedQueue, hence I'm wondering now if for Asynchronous logging
JCtools will perform better as I'm seeing some CPU spikes with LMAX and
Log4j2.
Regards,
Guido.
On Mon, Jan 25, 2016 at 5:26 PM, sampath kumar <sa...@gmail.com> wrote:
> Guido,
>
> Did you try using different waiting strategies of LMAX before trying
> JCTools ?
>
> Regards,
> Sampath
>
> On Mon, Jan 25, 2016 at 10:30 PM, Guido Medina <ox...@gmail.com> 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.
>>
>
>
>
> --
> Regards,
> Sampath
>
Re: LMAX vs Lampart
Posted by sampath kumar <sa...@gmail.com>.
Guido,
Did you try using different waiting strategies of LMAX before trying
JCTools ?
Regards,
Sampath
On Mon, Jan 25, 2016 at 10:30 PM, Guido Medina <ox...@gmail.com> 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.
>
--
Regards,
Sampath
Re: LMAX vs Lampart
Posted by sampath kumar <sa...@gmail.com>.
@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 <re...@gmail.com> 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 <bo...@gmail.com> wrote:
>
> It would be cool to see some JMH comparisons between the two approaches.
>
> On 26 January 2016 at 06:54, Guido Medina <ox...@gmail.com> 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 <
>> mikael.staldal@magine.com> 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 <
>>> mikael.staldal@magine.com> 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 <
>>>> mikael.staldal@magine.com> 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 <ox...@gmail.com>
>>>>> 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 <
>>>>>> mikael.staldal@magine.com> 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 <ox...@gmail.com>
>>>>>>> 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*
>>>>>>> mikael.staldal@magine.com
>>>>>>> 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*
>>>>> mikael.staldal@magine.com
>>>>> 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*
>>>> mikael.staldal@magine.com
>>>> 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*
>>> mikael.staldal@magine.com
>>> 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 <bo...@gmail.com>
>
>
--
Regards,
Sampath
Re: LMAX vs Lampart
Posted by Remko Popma <re...@gmail.com>.
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 <bo...@gmail.com> wrote:
>
> It would be cool to see some JMH comparisons between the two approaches.
>
>> On 26 January 2016 at 06:54, Guido Medina <ox...@gmail.com> 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 <mi...@magine.com> 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 <mi...@magine.com> 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 <mi...@magine.com> 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 <ox...@gmail.com> 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 <mi...@magine.com> 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 <ox...@gmail.com> 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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>> Mikael Ståldal
>>>>>>> Senior software developer
>>>>>>>
>>>>>>> Magine TV
>>>>>>> mikael.staldal@magine.com
>>>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>> Mikael Ståldal
>>>>> Senior software developer
>>>>>
>>>>> Magine TV
>>>>> mikael.staldal@magine.com
>>>>> 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.
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> Mikael Ståldal
>>>> Senior software developer
>>>>
>>>> Magine TV
>>>> mikael.staldal@magine.com
>>>> 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.
>>>
>>>
>>>
>>> --
>>>
>>>
>>> Mikael Ståldal
>>> Senior software developer
>>>
>>> Magine TV
>>> mikael.staldal@magine.com
>>> 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 <bo...@gmail.com>
Re: LMAX vs Lampart
Posted by Matt Sicker <bo...@gmail.com>.
It would be cool to see some JMH comparisons between the two approaches.
On 26 January 2016 at 06:54, Guido Medina <ox...@gmail.com> 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 <
> mikael.staldal@magine.com> 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 <
>> mikael.staldal@magine.com> 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 <
>>> mikael.staldal@magine.com> 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 <ox...@gmail.com>
>>>> 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 <
>>>>> mikael.staldal@magine.com> 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 <ox...@gmail.com>
>>>>>> 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*
>>>>>> mikael.staldal@magine.com
>>>>>> 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*
>>>> mikael.staldal@magine.com
>>>> 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*
>>> mikael.staldal@magine.com
>>> 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*
>> mikael.staldal@magine.com
>> 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 <bo...@gmail.com>
Re: LMAX vs Lampart
Posted by Guido Medina <ox...@gmail.com>.
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 <mi...@magine.com>
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 <mikael.staldal@magine.com
> > 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 <
>> mikael.staldal@magine.com> 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 <ox...@gmail.com> 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 <
>>>> mikael.staldal@magine.com> 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 <ox...@gmail.com>
>>>>> 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*
>>>>> mikael.staldal@magine.com
>>>>> 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*
>>> mikael.staldal@magine.com
>>> 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*
>> mikael.staldal@magine.com
>> 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*
> mikael.staldal@magine.com
> 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.
>
Re: LMAX vs Lampart
Posted by Mikael Ståldal <mi...@magine.com>.
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 <mi...@magine.com>
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 <mikael.staldal@magine.com
> > 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 <ox...@gmail.com> 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 <
>>> mikael.staldal@magine.com> 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 <ox...@gmail.com>
>>>> 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*
>>>> mikael.staldal@magine.com
>>>> 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*
>> mikael.staldal@magine.com
>> 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*
> mikael.staldal@magine.com
> 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*
mikael.staldal@magine.com
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.
Re: LMAX vs Lampart
Posted by Mikael Ståldal <mi...@magine.com>.
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 <mi...@magine.com>
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 <ox...@gmail.com> 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 <
>> mikael.staldal@magine.com> 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 <ox...@gmail.com> 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*
>>> mikael.staldal@magine.com
>>> 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*
> mikael.staldal@magine.com
> 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*
mikael.staldal@magine.com
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.
Re: LMAX vs Lampart
Posted by Mikael Ståldal <mi...@magine.com>.
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 <ox...@gmail.com> 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 <mikael.staldal@magine.com
> > 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 <ox...@gmail.com> 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*
>> mikael.staldal@magine.com
>> 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*
mikael.staldal@magine.com
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.
Re: LMAX vs Lampart
Posted by Guido Medina <ox...@gmail.com>.
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 <mi...@magine.com>
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 <ox...@gmail.com> 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*
> mikael.staldal@magine.com
> 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.
>
Re: LMAX vs Lampart
Posted by Mikael Ståldal <mi...@magine.com>.
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 <ox...@gmail.com> 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*
mikael.staldal@magine.com
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.