Hi Simon
I like this solution. It's short, easy to understand and avoids binary
incompatibility.
--
Dennis Lundberg
Simon Kitching wrote:
After some thought, I've changed my mind about the solution.
I think the best choice is instead to use a synchronized block:
// Append date-time
Hi Simon!
I think the best choice is instead to use a synchronized block:
This:
(a) Avoids any binary-compatibility issues, as the member is still
present and still used.
Maybe you would like to deprecate the member too, so this can be cleaned
up any time later.Though, its not that
+1. I like it.
-Original Message-
From: Simon Kitching [mailto:[EMAIL PROTECTED]
Sent: Saturday, October 14, 2006 11:12 PM
To: Jakarta Commons Developers List
Subject: Re: Logging: SimpleLog not thread-safe
After some thought, I've changed my mind about the solution.
I think the best
HI,
On Fri, 2006-10-13 at 00:10 -0400, Kenneth Xu wrote:
Yes, it'll be GC'ed when thread is. And initialized when first use in a new
thread. Here is the test code:
But if an application has long-running threads then the object won't be
recycled until the thread dies. So an app with 100 threads
You could just take a private copy of FastDateFormat from commons-lang
which is thread-safe. Might bloat your jar-file size though.
Stephen
Simon Kitching wrote:
HI,
On Fri, 2006-10-13 at 00:10 -0400, Kenneth Xu wrote:
Yes, it'll be GC'ed when thread is. And initialized when first use in a
Tomcat had this same issue a while back. It was trying to use a single
SimpleDateFormat object to parse/format date-valued HTTP headers. I
submitted the patch for it and I think we decided to just instantiate as
needed. Local variables are garbage collected much more reliably from
what I
On Sat, 2006-10-14 at 08:07 -0400, James Carman wrote:
Tomcat had this same issue a while back. It was trying to use a single
SimpleDateFormat object to parse/format date-valued HTTP headers. I
submitted the patch for it and I think we decided to just instantiate as
needed. Local variables
After some thought, I've changed my mind about the solution.
I think the best choice is instead to use a synchronized block:
// Append date-time if so configured
if(showDateTime) {
Date now = new Date();
String dateText;
performance than
creating one new in every log invocation.
Just my 2 cents,
Thanks,
Ken
-Original Message-
From: Simon Kitching [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 11, 2006 5:05 AM
To: Jakarta Commons Developers List
Subject: Re: Logging: SimpleLog not thread-safe
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 11, 2006 5:05 AM
To: Jakarta Commons Developers List
Subject: Re: Logging: SimpleLog not thread-safe
Hi Martin,
Thanks very much for letting us know about this. I think you're right
about there being a thread-safety issue.
SimpleLog
Commons Developers List
Subject: Re: Logging: SimpleLog not thread-safe
Hi Martin,
Thanks very much for letting us know about this. I think you're right
about there being a thread-safety issue.
SimpleLog is definitely in use, but obviously this bug will only be
triggered under pretty rare
to
reconstruct it from scratch.
-Original Message-
From: James Carman [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 12, 2006 6:23 AM
To: Jakarta Commons Developers List
Subject: RE: Logging: SimpleLog not thread-safe
How do you know when to clean it up? Just instantiate a new one each
:[EMAIL PROTECTED]
Sent: Thursday, October 12, 2006 10:26 AM
To: 'Jakarta Commons Developers List'
Subject: RE: Logging: SimpleLog not thread-safe
I guess it will clean itself up when the thread is garbage collected. I'd
play around with it just to be sure, though. Application servers typically
use
OTOH - how much time costs the creation and usage of such an object?
Good question. I wrote a rough test code and posted in my earlier email, the
result on my P-M 1.2G laptop is 2797 v.s. 22656 in 1M calls, so really not
much.
Hi Martin,
Thanks very much for letting us know about this. I think you're right
about there being a thread-safety issue.
SimpleLog is definitely in use, but obviously this bug will only be
triggered under pretty rare conditions, and I expect would usually just
result in a malformed date string
List
Subject: Re: Logging: SimpleLog not thread-safe
Hi Martin,
Thanks very much for letting us know about this. I think you're right
about there being a thread-safety issue.
SimpleLog is definitely in use, but obviously this bug will only be
triggered under pretty rare conditions, and I expect
Hi,
I'm not sure if anyone else uses the SimpleLog class - anyway I've
noticed that SimpleLog.log is not thread-safe. The following code
(starting on line 282):
if(showDateTime) {
buf.append(dateFormatter.format(new Date()));
buf.append( );
}
makes an
Solution: remove the dateFormatter instance variable and instantiate a
new DateFormat each time in the log method, e.g.
How about a ThreadLocal variable?
Thanks,
Ken
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
18 matches
Mail list logo
