Greetings,
A terse recap of performance on my J2ME on a slow single core env:
BasicContextSelector and BufferedIO=false for RollingFile DOES seem to equal
log4j v1 performance in my most recent benchmarks. I'm not comfortable with
this result because what happened is the V1 benchmarks jumped worse to equal
the V2 benchmarks without explanation. So I'm digging into that issue. But
I'm wanting to move to using V2's MDC to see if that has much of a perf hit for
just put'ing a few variables into ThreadContext and referencing them in the
Pattern: %X{transID} etc
The log4j-users-guide.pdf does not have any MDC API discussion, just
configuration parameters. This URL is all I've found:
http://logging.apache.org/log4j/2.x/manual/thread-context.html
Let me start by saying that most threads never die. They wait on queues so I
believe I never have to worry about ThreadContext.clear / removeStack etc. Or
Do I??
But to clarify proper API use, the above URL infers that thread local object
storage is cleaned up with ThreadContext.clear()
Maybe it's left over from V1 NDC but the JavaDoc on ThreadContext has some
strongly worded recommendation for calling ThreadContext.removeStack()
"Each thread that created a diagnostic context by calling
push(java.lang.String)<http://logging.apache.org/log4j/2.x/log4j-api/apidocs/org/apache/logging/log4j/ThreadContext.html>
should call this method before exiting. Otherwise, the memory used by the
thread cannot be reclaimed by the VM.
As this is such an important problem in heavy duty systems and because it is
difficult to always guarantee that the remove method is called before exiting a
thread, this method has been augmented to lazily remove references to dead
threads. In practice, this means that you can be a little sloppy and
occasionally forget to call
remove(java.lang.String)<http://logging.apache.org/log4j/2.x/log4j-api/apidocs/org/apache/logging/log4j/ThreadContext.html>
before exiting a thread. However, you must call remove sometime. If you never
call it, then your application is sure to run out of memory. "
I could use what the suggested cleanup of ThreadContext is??
Also: there's no reasoning for the getStack() vs getImutableStack(), my guess
is one uses a map.clone() and one doesn't. I need to bridge the context Map
around a queue so I do need to get the Map and then put the map elements back
into the servicing thread's context. I would like to avoid a map.clone/new Map
if I can. Which should I use: getStack or getImutableStack?
Thanks, curt
Curt Smith
AT&T Digital Life
DLC Software Development
404-499-7013
(cell) 678-365-6508
