I think it's much easier to discuss something concrete, so I've put up an
incomplete version of the AsyncAppenderSkeleton I envisage on the following
branch:
https://github.com/JJoe2/log4net/tree/wip/AsyncAppender
I would appreciate it if you could review this and let me know if you're happy
t
On 2016-11-04 10:37, Stefan Bodewig wrote:
On 2016-11-03, Joe wrote:
However I don’t understand your point about event formatters – are
there any formatters that aren’t thread safe? It doesn’t seem to be
an unreasonable restriction to require writers of formatters / layout
implementations to
either BufferingAppenderSkeleton or AppenderSkeleton. I’ll give it
some more thought and post again to justify this opinion soon(ish).
*From:*Dominik Psenner [mailto:dpsen...@gmail.com]
*Sent:* 03 November 2016 00:14
*To:* Log4NET Dev
*Subject:* Re: AsyncAppenderSkeleton
As far as I can recall
On 2016-11-03, Joe wrote:
> However I don’t understand your point about event formatters – are
> there any formatters that aren’t thread safe? It doesn’t seem to be
> an unreasonable restriction to require writers of formatters / layout
> implementations to be thread-safe.
It may not be unreason
AsyncAppenderSkeleton, that doesn’t inherit from either
BufferingAppenderSkeleton or AppenderSkeleton. I’ll give it some more thought
and post again to justify this opinion soon(ish).
From: Dominik Psenner [mailto:dpsen...@gmail.com]
Sent: 03 November 2016 00:14
To: Log4NET Dev
Subject: Re
don’t see what
> race condition could cause a message to be “broken up into elements from
> multiple thread contexts”?
>
>
>
> Can you throw any light on that?
>
>
>
>
>
>
>
> *From:* Dominik Psenner [mailto:dpsen...@apache.org]
> *Sent:* 31 October 2016 15:31
message to be "broken up into elements from multiple
thread contexts"?
Can you throw any light on that?
From: Dominik Psenner [mailto:dpsen...@apache.org]
Sent: 31 October 2016 15:31
To: log4net-dev@logging.apache.org
Subject: Re: AsyncAppenderSkeleton
See inlines.
On 2016-10-31 11:30
I've created https://issues.apache.org/jira/browse/LOG4NET-529 for this
From: Dominik Psenner [mailto:dpsen...@gmail.com]
Sent: 31 October 2016 15:33
To: log4net-dev@logging.apache.org
Subject: Re: AsyncAppenderSkeleton
These few lines alone are very suspicious indeed. Without fu
These few lines alone are very suspicious indeed. Without further
investigations I'm unable to give any sensible feedback.
On 2016-10-31 11:54, Joe wrote:
Another point is that for any asynchronous appender implementation,
it’s a sine qua non that the LoggingEvent class be thread-safe.
At l
See inlines.
On 2016-10-31 11:30, Joe wrote:
Hi Dominik,
Thanks for the feedback
> Please note also that MSMQ sounds like a MS only service and that would in turn mean that the .net core
variant would no longer be able to benefit from the
AsyncAppenderSkeleton. To me this outlines a path th
Another point is that for any asynchronous appender implementation, it's a sine
qua non that the LoggingEvent class be thread-safe.
At least for the manipulations an appender might do: layout, accessing
properties, fixing properties.
I had a quick browse through the source and found what looks
Hi Dominik,
Thanks for the feedback
> Please note also that MSMQ sounds like a MS only service and that would in
> turn mean that the .net core variant would no longer be able to benefit from
> the AsyncAppenderSkeleton. To me this outlines a path that we would not like
> to walk on
I don't s
Hi Joe!
On 2016-10-31 08:15, Joe wrote:
I have some ideas for developing a new AsyncAppenderSkeleton, based on
recent experience developing a custom async appender that sends
logging events to a Web API.
My current thoughts are:
1.A new base class AsyncAppenderSkeleton that can be configur
13 matches
Mail list logo
