On Sunday 26 September 2004 18:48, Ceki Gülcü wrote:
> In order to fix bug 24159, would it be possible for you to not log
> from within a synchronized resource which is also used from within
> rendering code?
May I quietly add, Mr Ross, that this is not at all unique to Log4J as a
subsy
At 09:39 PM 9/23/2004, Elias Ross wrote:
On Thu, 2004-09-23 at 01:59, Ceki Gülcü wrote:
> Some would say heavy-handed, others would say simple and robust. Given
> the history of this discussion (see bug report 24159), I have a strong
> bias against modifying the existing synchronization code in
>
On Thu, 23 Sep 2004 [EMAIL PROTECTED] wrote:
| --- Elias Ross <[EMAIL PROTECTED]> wrote:
| > I feel a bit frustrated because I've been bitten in the ass a few
| > times encountering this "contrived" problem and I haven't been
| > taken very seriously pointing this out. As I have tried to explain,
At 04:08 PM 9/23/2004 -0700, you wrote:
--- Elias Ross <[EMAIL PROTECTED]> wrote:
> I feel a bit frustrated because I've been bitten in the ass a few
> times encountering this "contrived" problem and I haven't been
> taken very seriously pointing this out. As I have tried to explain,
> this is som
--- Elias Ross <[EMAIL PROTECTED]> wrote:
> I feel a bit frustrated because I've been bitten in the ass a few
> times encountering this "contrived" problem and I haven't been
> taken very seriously pointing this out. As I have tried to explain,
> this is something that has happened before on serve
On Thu, 2004-09-23 at 01:59, Ceki GÃlcà wrote:
> Some would say heavy-handed, others would say simple and robust. Given
> the history of this discussion (see bug report 24159), I have a strong
> bias against modifying the existing synchronization code in
> AppenderSkeleton. The problem in 24159 i
At 10:23 PM 9/17/2004, Elias Ross wrote:
The java.io.Writer classes are synchronized internally. There is a lock
internally, so the only reason to lock externally is to synchronize
state on another operation. Say, if you do w.write(X); w.write(Y);
Agreed.
If you look at the way Layouts are des
On Fri, 2004-09-17 at 11:51, Ceki GÃlcà wrote:
> Do you realize that the main reason for synchronization in doAppend method
> is avoiding simultaneous writes to the same output device? Any write
> operation which is not synchronized (or otherwise protected against
> simultaneous access) is a big
av Shapira
Millennium Research Informatics
>-Original Message-
>From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
>Sent: Friday, September 17, 2004 2:51 PM
>To: Log4J Developers List; Log4J Developers List
>Subject: Re: Improving Log4J concurrency, avoiding deadlock
>
>
>Do yo
Do you realize that the main reason for synchronization in doAppend method
is avoiding simultaneous writes to the same output device? Any write
operation which is not synchronized (or otherwise protected against
simultaneous access) is a big no no...
At 08:35 PM 9/17/2004, Elias Ross wrote:
On
On Fri, 2004-09-17 at 11:35, Elias Ross wrote:
> If this is a concern, you might want to create some sort of semaphore so
> that when an event is being logged, the appender state can't be
> affected. However, as many concurrent events can be logged at the same
> time.
>
Instead of a semaphore,
On Fri, 2004-09-17 at 10:40, Ceki GÃlcà wrote:
> Elias,
>
> How are your changes compatible with log4j 1.3 where layouts write directly
> to the output stream without intermediary String objects?
It would seem the same issue would occur if an appender is locked when a
layout is writing directly
Elias,
How are your changes compatible with log4j 1.3 where layouts write directly
to the output stream without intermediary String objects?
At 07:35 PM 9/17/2004, Elias Ross wrote:
I had a created a way to avoid a deadlock condition when Appender is
holding on to a lock and rendering an object.
I had a created a way to avoid a deadlock condition when Appender is
holding on to a lock and rendering an object. In some situations,
attempting to log during a toString() causes this. Refer to to Bugzilla
bug:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24159
To understand why this is
14 matches
Mail list logo
