I came to the conclusion that it wouldn't fix it. You can review the
java memory model mailing list for today to find out why. Look for the
"solution to double-check locking" thread.
James Stauffer wrote:
I have thought that pattern would fix the problem also but I have
never seen anyone men
I have thought that pattern would fix the problem also but I have
never seen anyone mention it before.
On 12/2/05, Trenton D. Adams <[EMAIL PROTECTED]> wrote:
> Actually, a co-worker and I just came up with a possible solution.
>
> public static Object getInstance()
> {
>if (instance == null)
On Dec 2, 2005, at 6:44 AM, Endre Stølsvik wrote:
log4j should -definately- be -extremely into- synchronization
issues. I
myself log -a whole lot-, and if I'm hit by synchs on every log
even if
the debug or trace is turned off, this will eat a -ton- of time.
Remember
that synching becomes
J Users List
Subject: Re: log4j multithreading performance
Actually, a co-worker and I just came up with a possible solution.
public static Object getInstance()
{
if (instance == null)
createInstance();
return instance;
}
private static synchronized void createInstance() {
We have recently had some nasty problems w/ log4j synchronization. This was
laid out in a recent post to this list; "threading issue with log4j" on Nov
23, 2005
It is a problem w/ the 1.2.X code base, which synchronizes within the
callAppenders method of Category. This is a fundamental class of lo
Actually, a co-worker and I just came up with a possible solution.
public static Object getInstance()
{
if (instance == null)
createInstance();
return instance;
}
private static synchronized void createInstance()
{
if (instance == null)
instance = new Object();
}
So, we end up ha
On Fri, 2 Dec 2005, Curt Arnold wrote:
|
| On Dec 2, 2005, at 12:19 AM, Trenton D. Adams wrote:
| >
| > Could the optimizer move the "instanceIndicator = 1" up one line? Perhaps by
| > analyzing exactly what's happening it could, because it knows, or *thinks*
| > it won't affect anything.
|
|
On Dec 2, 2005, at 12:19 AM, Trenton D. Adams wrote:
Could the optimizer move the "instanceIndicator = 1" up one line?
Perhaps by analyzing exactly what's happening it could, because it
knows, or *thinks* it won't affect anything.
Sorry way off topic now, we aren't the best people to giv
Trenton D. Adams wrote:
Curt Arnold wrote:
On Dec 1, 2005, at 8:39 PM, Trenton D. Adams wrote:
As a general rule, singleton methods should not be synchronized for
performance reasons. If this method is only called once in awhile,
no big deal. But, if it's called regularly, then it can
Curt Arnold wrote:
On Dec 1, 2005, at 8:39 PM, Trenton D. Adams wrote:
As a general rule, singleton methods should not be synchronized for
performance reasons. If this method is only called once in awhile,
no big deal. But, if it's called regularly, then it can be a really
big perform
On Dec 1, 2005, at 8:39 PM, Trenton D. Adams wrote:
As a general rule, singleton methods should not be synchronized for
performance reasons. If this method is only called once in awhile,
no big deal. But, if it's called regularly, then it can be a
really big performance problem. Does t
LF5 has been removed in log4j1.3 (replaced by Chainsaw v2.
Paul
On 02/12/2005, at 1:39 PM, Trenton D. Adams wrote:
Hi guys,
Please don't take this as bad criticism. I'm just trying to
provide some *useful* insights. And besides, I think you guys are
doing a great job on log4j.
I just
Hi guys,
Please don't take this as bad criticism. I'm just trying to provide
some *useful* insights. And besides, I think you guys are doing a great
job on log4j.
I just read on the internet how log4j uses synchronized methods
everywhere. I'm not too sure if it's true or not. But, a grep
13 matches
Mail list logo
