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 Mikael Ståldal <mi...@magine.com> on 2016/12/12 17:16:36 UTC
(a)sync appenders
This issue: https://issues.apache.org/jira/browse/LOG4J2-1733
raises an architectural issue.
As far as I understand, Log4j assumes that regular appenders (the
AsyncAppender is a special case) to be synchronous, and
provides AsyncAppender and async loggers if you want async behavior.
It would be easy to fulfill LOG4J2-1733 and add an option to make
KafkaAppeder asynchronous. But that that would violate the contract, and
might cause problems that are not so easy to foresee.
However, refusing LOG4J2-1733 and insisting in keeping all appenders
synchronous, even when real async I/O is available, will limit performance.
Should we refine the appender interface and explicitly allow them to be
asynchronous, changing AsyncAppender and parts of core to make use of this
to optimize processing?
Thoughts?
--
[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: (a)sync appenders
Posted by Gary Gregory <ga...@gmail.com>.
I do not like having re-invent the Java 8 wheel like we did with the
message supplier mess where we ended up deprecating a whole bunch of APIs
we had _just_ introduced. I think we need to either migrate to Java 8 or
put things like this on the to-do list for when we do move to Java 8. If
there is a Java 7-way to do this, then that's another thing...
Gary
On Mon, Dec 12, 2016 at 10:27 AM, Matt Sicker <bo...@gmail.com> wrote:
> Without Java 8 support, we'll need our own promise-like API then most
> likely.
>
> On 12 December 2016 at 11:37, Mikael Ståldal <mi...@magine.com>
> wrote:
>
>> The java.util.concurrent.Future is quite useless since it does not
>> support callbacks. We should not use it.
>>
>> On Mon, Dec 12, 2016 at 6:30 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>>> There was talk about making NIO/channel-based appenders that would get
>>> nearly async performance without using async loggers or appenders. I'm not
>>> so sure that making an appender's implementation asynchronous/non-blocking
>>> is against the architecture. Though adding API support for Future or
>>> CompleteableFuture or something similar would be interesting. It could
>>> certainly open up some avenues for asynchronous optimizations or new ideas.
>>>
>>> On 12 December 2016 at 11:16, Mikael Ståldal <mi...@magine.com>
>>> wrote:
>>>
>>>> This issue: https://issues.apache.org/jira/browse/LOG4J2-1733
>>>> raises an architectural issue.
>>>>
>>>> As far as I understand, Log4j assumes that regular appenders (the
>>>> AsyncAppender is a special case) to be synchronous, and
>>>> provides AsyncAppender and async loggers if you want async behavior.
>>>>
>>>> It would be easy to fulfill LOG4J2-1733 and add an option to make
>>>> KafkaAppeder asynchronous. But that that would violate the contract, and
>>>> might cause problems that are not so easy to foresee.
>>>>
>>>> However, refusing LOG4J2-1733 and insisting in keeping all appenders
>>>> synchronous, even when real async I/O is available, will limit performance.
>>>>
>>>> Should we refine the appender interface and explicitly allow them to be
>>>> asynchronous, changing AsyncAppender and parts of core to make use of this
>>>> to optimize processing?
>>>>
>>>> Thoughts?
>>>>
>>>> --
>>>> [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>
>>>
>>
>>
>>
>> --
>> [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>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: (a)sync appenders
Posted by Matt Sicker <bo...@gmail.com>.
Without Java 8 support, we'll need our own promise-like API then most
likely.
On 12 December 2016 at 11:37, Mikael Ståldal <mi...@magine.com>
wrote:
> The java.util.concurrent.Future is quite useless since it does not support
> callbacks. We should not use it.
>
> On Mon, Dec 12, 2016 at 6:30 PM, Matt Sicker <bo...@gmail.com> wrote:
>
>> There was talk about making NIO/channel-based appenders that would get
>> nearly async performance without using async loggers or appenders. I'm not
>> so sure that making an appender's implementation asynchronous/non-blocking
>> is against the architecture. Though adding API support for Future or
>> CompleteableFuture or something similar would be interesting. It could
>> certainly open up some avenues for asynchronous optimizations or new ideas.
>>
>> On 12 December 2016 at 11:16, Mikael Ståldal <mi...@magine.com>
>> wrote:
>>
>>> This issue: https://issues.apache.org/jira/browse/LOG4J2-1733
>>> raises an architectural issue.
>>>
>>> As far as I understand, Log4j assumes that regular appenders (the
>>> AsyncAppender is a special case) to be synchronous, and
>>> provides AsyncAppender and async loggers if you want async behavior.
>>>
>>> It would be easy to fulfill LOG4J2-1733 and add an option to make
>>> KafkaAppeder asynchronous. But that that would violate the contract, and
>>> might cause problems that are not so easy to foresee.
>>>
>>> However, refusing LOG4J2-1733 and insisting in keeping all appenders
>>> synchronous, even when real async I/O is available, will limit performance.
>>>
>>> Should we refine the appender interface and explicitly allow them to be
>>> asynchronous, changing AsyncAppender and parts of core to make use of this
>>> to optimize processing?
>>>
>>> Thoughts?
>>>
>>> --
>>> [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>
>>
>
>
>
> --
> [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: (a)sync appenders
Posted by Mikael Ståldal <mi...@magine.com>.
The java.util.concurrent.Future is quite useless since it does not support
callbacks. We should not use it.
On Mon, Dec 12, 2016 at 6:30 PM, Matt Sicker <bo...@gmail.com> wrote:
> There was talk about making NIO/channel-based appenders that would get
> nearly async performance without using async loggers or appenders. I'm not
> so sure that making an appender's implementation asynchronous/non-blocking
> is against the architecture. Though adding API support for Future or
> CompleteableFuture or something similar would be interesting. It could
> certainly open up some avenues for asynchronous optimizations or new ideas.
>
> On 12 December 2016 at 11:16, Mikael Ståldal <mi...@magine.com>
> wrote:
>
>> This issue: https://issues.apache.org/jira/browse/LOG4J2-1733
>> raises an architectural issue.
>>
>> As far as I understand, Log4j assumes that regular appenders (the
>> AsyncAppender is a special case) to be synchronous, and
>> provides AsyncAppender and async loggers if you want async behavior.
>>
>> It would be easy to fulfill LOG4J2-1733 and add an option to make
>> KafkaAppeder asynchronous. But that that would violate the contract, and
>> might cause problems that are not so easy to foresee.
>>
>> However, refusing LOG4J2-1733 and insisting in keeping all appenders
>> synchronous, even when real async I/O is available, will limit performance.
>>
>> Should we refine the appender interface and explicitly allow them to be
>> asynchronous, changing AsyncAppender and parts of core to make use of this
>> to optimize processing?
>>
>> Thoughts?
>>
>> --
>> [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>
>
--
[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: (a)sync appenders
Posted by Remko Popma <re...@gmail.com>.
I agree with Gary and don't see any problem with exposing async features of the underlying library used in Appenders.
Sure, such features will not be controlled by Log4j queues or locks or other concurrency mechanisms but that is not a problem.
We should just document how to enable these features and then it's up to users.
Sent from my iPhone
> On 13 Dec 2016, at 4:28, Matt Sicker <bo...@gmail.com> wrote:
>
> The main thing about synchronicity that we're relying on here is that Appenders are called synchronously. To relieve the performance issues with doing that on blocking appenders, a user can use async loggers or an async appender wrapper for simplicity. However, I don't see why an appender couldn't be asynchronously implemented.
>
> Adding more explicit support for asynchronous appenders (e.g., a sort of promise-based API) would be a different story since I think all of our current appenders use synchronous APIs (except maybe ListAppender?).
>
>> On 12 December 2016 at 12:55, Gary Gregory <ga...@gmail.com> wrote:
>>> On Mon, Dec 12, 2016 at 9:30 AM, Matt Sicker <bo...@gmail.com> wrote:
>>> There was talk about making NIO/channel-based appenders that would get nearly async performance without using async loggers or appenders. I'm not so sure that making an appender's implementation asynchronous/non-blocking is against the architecture.
>>
>> We do not specify that appender MUST be synchronous anywhere:
>>
>> - https://logging.apache.org/log4j/2.x/manual/architecture.html
>> - https://logging.apache.org/log4j/2.x/manual/appenders.html
>> - https://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/apache/logging/log4j/core/Appender.html
>>
>> We do talk about how to make code paths explicitly _asynchronous_.
>>
>> I seems quite OK to surface whatever bells and whistle the underlying library provides for an appender. I do not see why we should lock users out of these feature. For me, it's about give users choices and documenting them.
>>
>> Gary
>>
>>
>>> Though adding API support for Future or CompleteableFuture or something similar would be interesting. It could certainly open up some avenues for asynchronous optimizations or new ideas.
>>>
>>>> On 12 December 2016 at 11:16, Mikael Ståldal <mi...@magine.com> wrote:
>>>> This issue: https://issues.apache.org/jira/browse/LOG4J2-1733
>>>> raises an architectural issue.
>>>>
>>>> As far as I understand, Log4j assumes that regular appenders (the AsyncAppender is a special case) to be synchronous, and provides AsyncAppender and async loggers if you want async behavior.
>>>>
>>>> It would be easy to fulfill LOG4J2-1733 and add an option to make KafkaAppeder asynchronous. But that that would violate the contract, and might cause problems that are not so easy to foresee.
>>>>
>>>> However, refusing LOG4J2-1733 and insisting in keeping all appenders synchronous, even when real async I/O is available, will limit performance.
>>>>
>>>> Should we refine the appender interface and explicitly allow them to be asynchronous, changing AsyncAppender and parts of core to make use of this to optimize processing?
>>>>
>>>> Thoughts?
>>>>
>>>> --
>>>>
>>>>
>>>> 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>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
Re: (a)sync appenders
Posted by Matt Sicker <bo...@gmail.com>.
The main thing about synchronicity that we're relying on here is that
Appenders are called synchronously. To relieve the performance issues with
doing that on blocking appenders, a user can use async loggers or an async
appender wrapper for simplicity. However, I don't see why an appender
couldn't be asynchronously implemented.
Adding more explicit support for asynchronous appenders (e.g., a sort of
promise-based API) would be a different story since I think all of our
current appenders use synchronous APIs (except maybe ListAppender?).
On 12 December 2016 at 12:55, Gary Gregory <ga...@gmail.com> wrote:
> On Mon, Dec 12, 2016 at 9:30 AM, Matt Sicker <bo...@gmail.com> wrote:
>
>> There was talk about making NIO/channel-based appenders that would get
>> nearly async performance without using async loggers or appenders. I'm not
>> so sure that making an appender's implementation asynchronous/non-blocking
>> is against the architecture.
>>
>
> We do not specify that appender MUST be synchronous anywhere:
>
> - https://logging.apache.org/log4j/2.x/manual/architecture.html
> - https://logging.apache.org/log4j/2.x/manual/appenders.html
> - https://logging.apache.org/log4j/2.x/log4j-core/apidocs/
> org/apache/logging/log4j/core/Appender.html
>
> We do talk about how to make code paths explicitly _asynchronous_.
>
> I seems quite OK to surface whatever bells and whistle the underlying
> library provides for an appender. I do not see why we should lock users out
> of these feature. For me, it's about give users choices and documenting
> them.
>
> Gary
>
>
>
>> Though adding API support for Future or CompleteableFuture or something
>> similar would be interesting. It could certainly open up some avenues for
>> asynchronous optimizations or new ideas.
>>
>> On 12 December 2016 at 11:16, Mikael Ståldal <mi...@magine.com>
>> wrote:
>>
>>> This issue: https://issues.apache.org/jira/browse/LOG4J2-1733
>>> raises an architectural issue.
>>>
>>> As far as I understand, Log4j assumes that regular appenders (the
>>> AsyncAppender is a special case) to be synchronous, and
>>> provides AsyncAppender and async loggers if you want async behavior.
>>>
>>> It would be easy to fulfill LOG4J2-1733 and add an option to make
>>> KafkaAppeder asynchronous. But that that would violate the contract, and
>>> might cause problems that are not so easy to foresee.
>>>
>>> However, refusing LOG4J2-1733 and insisting in keeping all appenders
>>> synchronous, even when real async I/O is available, will limit performance.
>>>
>>> Should we refine the appender interface and explicitly allow them to be
>>> asynchronous, changing AsyncAppender and parts of core to make use of this
>>> to optimize processing?
>>>
>>> Thoughts?
>>>
>>> --
>>> [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>
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
> JUnit in Action, Second Edition
> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
> Spring Batch in Action
> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
Matt Sicker <bo...@gmail.com>
Re: (a)sync appenders
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Dec 12, 2016 at 9:30 AM, Matt Sicker <bo...@gmail.com> wrote:
> There was talk about making NIO/channel-based appenders that would get
> nearly async performance without using async loggers or appenders. I'm not
> so sure that making an appender's implementation asynchronous/non-blocking
> is against the architecture.
>
We do not specify that appender MUST be synchronous anywhere:
- https://logging.apache.org/log4j/2.x/manual/architecture.html
- https://logging.apache.org/log4j/2.x/manual/appenders.html
-
https://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/apache/logging/log4j/core/Appender.html
We do talk about how to make code paths explicitly _asynchronous_.
I seems quite OK to surface whatever bells and whistle the underlying
library provides for an appender. I do not see why we should lock users out
of these feature. For me, it's about give users choices and documenting
them.
Gary
> Though adding API support for Future or CompleteableFuture or something
> similar would be interesting. It could certainly open up some avenues for
> asynchronous optimizations or new ideas.
>
> On 12 December 2016 at 11:16, Mikael Ståldal <mi...@magine.com>
> wrote:
>
>> This issue: https://issues.apache.org/jira/browse/LOG4J2-1733
>> raises an architectural issue.
>>
>> As far as I understand, Log4j assumes that regular appenders (the
>> AsyncAppender is a special case) to be synchronous, and
>> provides AsyncAppender and async loggers if you want async behavior.
>>
>> It would be easy to fulfill LOG4J2-1733 and add an option to make
>> KafkaAppeder asynchronous. But that that would violate the contract, and
>> might cause problems that are not so easy to foresee.
>>
>> However, refusing LOG4J2-1733 and insisting in keeping all appenders
>> synchronous, even when real async I/O is available, will limit performance.
>>
>> Should we refine the appender interface and explicitly allow them to be
>> asynchronous, changing AsyncAppender and parts of core to make use of this
>> to optimize processing?
>>
>> Thoughts?
>>
>> --
>> [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>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: (a)sync appenders
Posted by Matt Sicker <bo...@gmail.com>.
There was talk about making NIO/channel-based appenders that would get
nearly async performance without using async loggers or appenders. I'm not
so sure that making an appender's implementation asynchronous/non-blocking
is against the architecture. Though adding API support for Future or
CompleteableFuture or something similar would be interesting. It could
certainly open up some avenues for asynchronous optimizations or new ideas.
On 12 December 2016 at 11:16, Mikael Ståldal <mi...@magine.com>
wrote:
> This issue: https://issues.apache.org/jira/browse/LOG4J2-1733
> raises an architectural issue.
>
> As far as I understand, Log4j assumes that regular appenders (the
> AsyncAppender is a special case) to be synchronous, and
> provides AsyncAppender and async loggers if you want async behavior.
>
> It would be easy to fulfill LOG4J2-1733 and add an option to make
> KafkaAppeder asynchronous. But that that would violate the contract, and
> might cause problems that are not so easy to foresee.
>
> However, refusing LOG4J2-1733 and insisting in keeping all appenders
> synchronous, even when real async I/O is available, will limit performance.
>
> Should we refine the appender interface and explicitly allow them to be
> asynchronous, changing AsyncAppender and parts of core to make use of this
> to optimize processing?
>
> Thoughts?
>
> --
> [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>