On Sep 18, 2011, at 6:01 PM, Joern Huxhorn wrote:
> Which reminds me, completely off-topic, of another idea concerning a custom
> Message implementation:
> A ThreadDumpMessage that would not get any parameter at all and would consist
> of a ThreadDump if it is actually logged, including the ThreadGroup info etc..
> This would have helped me immensely in the past. Instead, I had to trigger
> thread dumps via SIG_QUIT at a random points of execution.
>
> Such a Message wouldn't be used in production under normal circumstances but
> could be enabled in case of strange concurrency issues...
>
> Joern.
>
What do you think about an optional LazyRenderMessage interface (I'm sure there
is a better name for this) that could be used by Message types that have
expensive constructers?
interface LazyRenderMessage {
void render();
}
The logger would call render() immediately after checking isEnabled for level
and marker. So, this should not affect serialization - the object will either
be fully constructed or discarded right away.
This would allow ThreadDumpMessage Thread.getAllStackTraces() work to be
avoided unless logging will actually occur (or is likely to occur in the case
of complex filters).
The benefit of course is that trace(THREAD_DUMP_MARKER, new
ThreadDumpMessage()) could be left in production code without if
isTraceEnabled(...) { ... }, and with very little overhead - creating a short
lived object that does nothing in the constructor is pretty cheap these days.
This would also help for Message types like ParameterizedMessage to avoid
parseArguments(arguments) when they are created by application code.
John
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
