On Sep 19, 2011, at 3:19 PM, Joern Huxhorn wrote:
>
> On 19.09.2011, at 22:09, ralph.goers @dslextreme.com wrote:
>
>>
>>
>> On Mon, Sep 19, 2011 at 1:07 PM, ralph.goers @dslextreme.com
>> <ralph.go...@dslextreme.com> wrote:
>>
>>
>> On Mon, Sep 19, 2011 at 10:07 AM, John Vasileff <john.li...@gmail.com> wrote:
>>
>> 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.
>>
>> I see some merit in this idea. But you are right, it really needs a better
>> name.
>>
>> One other point, though, is that there should always be a constructor that
>> allows immediate rendering. I could easily see the ThreadDumpMessage being
>> used for other purposes and never being passed to a logger. For example, I
>> could create two ThreadDumpMessages at slightly different points in time and
>> then only print the differences between them.
>>
>
> But the whole idea of the Message interface was the lazy evaluation of the
> expensive String creation with the suggestion to also cache those strings for
> reuse. Otherwise using toString() wouldn't make a big difference...
>
> Printing the differences between two ThreadDumpMessages would be an
> additional functionality, of course. I guess that something like a populate()
> method filling in the stacktrace (separate from string creation) would make
> sense. That could be called automatically if it wasn't called explicitly
> before execution of getFormattedMessage()...
A ThreadDumpMessage pretty much has to capture all the data immediately or its
usefulness would be quite limited. If you look at the way I implemented that
class you will see it captures the thread information in the constructor.
However, it doesn't actually build the formatted String until the first call to
getFormattedMessage. This is actually what you would want if one were to
create a ThreadDumpDiffMessage.
John's proposal is to have the ThreadDumpMessage constructor do nothing. The
Thread data wouldn't be captured until the render method is called. You've
basically said the same thing with regard to the populate method. Although my
preference would be to have constructors that allow for both I guess I'd also
be OK with having the populate/render/initialize method return the Message so
that you could do
ThreadDumpMessage msg = new ThreadDumpMessage.populate();
If Logger is going to call the populate method then it obviously has to check
whether that has already been done.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
