Re: Would it be worth it to make the BlockingQueue implementation configurable in AsyncAppender?

I do not think Java 8 adds anything in this area: https://docs.oracle.com/javase/8/docs/technotes/guides/concurrency/changes8.html Gary On Wed, Jun 15, 2016 at 6:17 PM, Remko Popma wrote: > Matt, > > Would you be interested in also looking at using TransferQueue in >

Re: Would it be worth it to make the BlockingQueue implementation configurable in AsyncAppender?

That looks interesting, yeah. On 15 June 2016 at 20:17, Remko Popma wrote: > Matt, > > Would you be interested in also looking at using TransferQueue in > AsyncAppender? > ( > https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/TransferQueue.html > ) > > Remko

Re: Would it be worth it to make the BlockingQueue implementation configurable in AsyncAppender?

Matt, Would you be interested in also looking at using TransferQueue in AsyncAppender? (https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/TransferQueue.html ) Remko Sent from my iPhone > On 2016/06/16, at 9:33, Matt Sicker wrote: > > What I found really neat

Re: Would it be worth it to make the BlockingQueue implementation configurable in AsyncAppender?

What I found really neat about the Conversant disruptor is that it doesn't use sun.misc.Unsafe which makes it a bit more future-proof. On the other hand, the main developer said it's optimised for Intel architectures, so it's somewhat special purpose. On 15 June 2016 at 19:14, Remko Popma

Re: Would it be worth it to make the BlockingQueue implementation configurable in AsyncAppender?

Very nice numbers! I think this would be a great addition to Log4j 2. As with any improvement that is performance-centric, we should add a section to the Performance page that compares the new capability to the previous options. It would be great if we can run these benchmarks for a number of

Re: Would it be worth it to make the BlockingQueue implementation configurable in AsyncAppender?

I was thinking of a log4j system property. On 15 June 2016 at 17:06, Gary Gregory wrote: > I do not like when software is too clever, like using some class from a > third party when it happens to be on the classpath, which I might not have > intended through a transitive

Re: Would it be worth it to make the BlockingQueue implementation configurable in AsyncAppender?

I do not like when software is too clever, like using some class from a third party when it happens to be on the classpath, which I might not have intended through a transitive third party dependency. IOW, to use an optional class like a FooQueue, I should tell Log4j that I want that enabled and

Re: Would it be worth it to make the BlockingQueue implementation configurable in AsyncAppender?

Alright, I've made . I'll make a proof of concept branch for this. On 15 June 2016 at 12:33, Matt Sicker wrote: > I have two approaches possible here: an optional dependency on Conversant > Disruptor to replace

Re: Would it be worth it to make the BlockingQueue implementation configurable in AsyncAppender?

I have two approaches possible here: an optional dependency on Conversant Disruptor to replace ArrayBlockingQueue, or a more generic BlockingQueueFactory that can be specified by a log4j property. I'll go make a jira issue for this. On 15 June 2016 at 11:28, Ralph Goers

Re: Would it be worth it to make the BlockingQueue implementation configurable in AsyncAppender?

This is still a pretty good option. I would modify the code to use that option if the library is present, otherwise fall back to ArrayBlockingQueue. Ralph > On Jun 15, 2016, at 9:24 AM, Matt Sicker wrote: > > Using the 4 threads versions of the benchmarks, here's what I've

Re: Would it be worth it to make the BlockingQueue implementation configurable in AsyncAppender?

Using the 4 threads versions of the benchmarks, here's what I've found: *ArrayBlockingQueue:* Benchmark Mode SamplesScore Error Units o.a.l.l.p.j.AsyncAppenderLog4j2Benchmark.throughput10Paramsthrpt 20 1101267.173 ±

Re: Would it be worth it to make the BlockingQueue implementation configurable in AsyncAppender?

I'm gonna play with the microbenchmarks and see what I find number-wise. I'll return with some results. On 15 June 2016 at 10:33, Matt Sicker wrote: > There's a much smaller disruptor library: < > https://github.com/conversant/disruptor> which implements BlockingQueue. > I'm

Would it be worth it to make the BlockingQueue implementation configurable in AsyncAppender?

There's a much smaller disruptor library: < https://github.com/conversant/disruptor> which implements BlockingQueue. I'm not sure how it compares in performance to LMAX (it's supposedly better on Intel machines), but it might be worth looking into as an alternative (or at least making a