Re: Making copies of LogEvent to avoid no-GC problems

[Gary Gregory]

On Thu, Jan 26, 2017 at 2:45 PM, Remko Popma  wrote:

> Yes, makes sense to me.
> Remko
>

I have a patch attached here:
https://issues.apache.org/jira/browse/LOG4J2-1807

But I'd like to be able to build on Windows before committing it...

Gary


>
> Sent from my iPhone
>
> On Jan 27, 2017, at 3:32, Gary Gregory  wrote:
>
> Hi All:
>
> Just like in our SMTP appender, I have a custom Appender which needs to
> track LogEvents. To do this without falling prey to all of our no-GC epic
> cleverness, the SMTP appender does this:
>
> public void add(LogEvent event) {
> if (event instanceof Log4jLogEvent && event.getMessage()
> instanceof ReusableMessage) {
> ((Log4jLogEvent) event).makeMessageImmutable();
> } else if (event instanceof MutableLogEvent) {
> event = ((MutableLogEvent) event).createMemento();
> }
> buffer.add(event);
> }
>
> The code in my Appender is functionally identical, I just use a different
> buffer type.
>
> This kind of Appender code is impossible to write correctly first IMO.
>
> My first implementation was just:
>
> public void add(LogEvent event) {
> buffer.add(event);
> }
>
> After a bug hunt by a colleague of mine, I thought the fix for our use
> case was 'simple':
>
> public void add(LogEvent event) {
> buffer.add(event instanceof MutableLogEvent ? ((MutableLogEvent)
> event).createMemento() : event);
> }
>
> But that was not complete!
>
> Our Appender now does the same thing the SMTP Appender does.
>
> Should we allow LogEvent to express this more cleanly? Maybe:
>
> public void add(LogEvent event) {
> buffer.add(event.asImmutableLogEvent());
> }
>
> Where MutableLogEvent.asImmutableLogEvent() just calls createMemento()
> and LogEvent changes its internal state by calling makeMessageImmutable()
> and returns 'this' since creating a new LogEvent is not needed.
>
> Thoughts?
>
> Gary
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
>
> 
> JUnit in Action, Second Edition
> 
>
> 
> Spring Batch in Action
> 
> 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Making copies of LogEvent to avoid no-GC problems

[Remko Popma]

Yes, makes sense to me. 
Remko 

Sent from my iPhone

> On Jan 27, 2017, at 3:32, Gary Gregory  wrote:
> 
> Hi All:
> 
> Just like in our SMTP appender, I have a custom Appender which needs to track 
> LogEvents. To do this without falling prey to all of our no-GC epic 
> cleverness, the SMTP appender does this:
> 
> public void add(LogEvent event) {
> if (event instanceof Log4jLogEvent && event.getMessage() instanceof 
> ReusableMessage) {
> ((Log4jLogEvent) event).makeMessageImmutable();
> } else if (event instanceof MutableLogEvent) {
> event = ((MutableLogEvent) event).createMemento();
> }
> buffer.add(event);
> }
> 
> The code in my Appender is functionally identical, I just use a different 
> buffer type.
> 
> This kind of Appender code is impossible to write correctly first IMO.
> 
> My first implementation was just:
> 
> public void add(LogEvent event) {
> buffer.add(event);
> }
> 
> After a bug hunt by a colleague of mine, I thought the fix for our use case 
> was 'simple':
> 
> public void add(LogEvent event) {
> buffer.add(event instanceof MutableLogEvent ? ((MutableLogEvent) 
> event).createMemento() : event);
> }
> 
> But that was not complete! 
> 
> Our Appender now does the same thing the SMTP Appender does.
> 
> Should we allow LogEvent to express this more cleanly? Maybe:
> 
> public void add(LogEvent event) {
> buffer.add(event.asImmutableLogEvent());
> }
> 
> Where MutableLogEvent.asImmutableLogEvent() just calls createMemento() and 
> LogEvent changes its internal state by calling makeMessageImmutable() and 
> returns 'this' since creating a new LogEvent is not needed.
> 
> Thoughts?
> 
> Gary
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
> Java Persistence with Hibernate, Second Edition 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com 
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

Making copies of LogEvent to avoid no-GC problems

[Gary Gregory]

Hi All:

Just like in our SMTP appender, I have a custom Appender which needs to
track LogEvents. To do this without falling prey to all of our no-GC epic
cleverness, the SMTP appender does this:

public void add(LogEvent event) {
if (event instanceof Log4jLogEvent && event.getMessage() instanceof
ReusableMessage) {
((Log4jLogEvent) event).makeMessageImmutable();
} else if (event instanceof MutableLogEvent) {
event = ((MutableLogEvent) event).createMemento();
}
buffer.add(event);
}

The code in my Appender is functionally identical, I just use a different
buffer type.

This kind of Appender code is impossible to write correctly first IMO.

My first implementation was just:

public void add(LogEvent event) {
buffer.add(event);
}

After a bug hunt by a colleague of mine, I thought the fix for our use case
was 'simple':

public void add(LogEvent event) {
buffer.add(event instanceof MutableLogEvent ? ((MutableLogEvent)
event).createMemento() : event);
}

But that was not complete!

Our Appender now does the same thing the SMTP Appender does.

Should we allow LogEvent to express this more cleanly? Maybe:

public void add(LogEvent event) {
buffer.add(event.asImmutableLogEvent());
}

Where MutableLogEvent.asImmutableLogEvent() just calls createMemento() and
LogEvent changes its internal state by calling makeMessageImmutable() and
returns 'this' since creating a new LogEvent is not needed.

Thoughts?

Gary

-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory