Mikael, Your changes impact the GelfLayout class mostly, right? Any other class impacted that you want me to take a look at? If not and all tests pass I'd say just go ahead and merge into master.
About testing whether it is allocation-free, there is this ticket LOG4J2-1295 <https://issues.apache.org/jira/browse/LOG4J2-1295> that is still open. I'm thinking the Allocation Instrumenter ( https://github.com/google/allocation-instrumenter) would serve our purposes quite well here. I just haven't had the bandwidth to look at this in more depth. It probably involves running a test in a separate VM with the -agent startup option. Not sure if we can do that with a normal log4j junit test or whether the test would need to start a separate VM with the proper startup options and then get that the result of that process via a file or something... It would actually be really good if you or someone else could make progress on that Jira, because I currently don't have the bandwidth to look at it yet. On Sat, Mar 12, 2016 at 1:33 AM, Mikael Ståldal <[email protected]> wrote: > Is it OK to merge to master? > > Remko, can you help me to verify that it is properly allocation-free (when > using > <GelfLayout host="test" compressionType="OFF"/>)? > > > On Tue, Mar 8, 2016 at 5:36 PM, Mikael Ståldal <[email protected]> > wrote: > >> I did it a bit differently, but now there are unit tests for >> GelfLayout.encode(). >> >> On Tue, Mar 8, 2016 at 3:51 PM, Remko Popma <[email protected]> >> wrote: >> >>> I added some tests to PatternLayoutTest, please take a look. >>> >>> On Tue, Mar 8, 2016 at 11:56 PM, Mikael Ståldal < >>> [email protected]> wrote: >>> >>>> I have done some work on this for GelfLayout. Please review branch >>>> gelf-layout-gc-free >>>> >>>> Is there any convenient way to unit-test the encode method of a layout? >>>> Do we do that for PatternLayout? >>>> >>>> On Wed, Feb 24, 2016 at 11:48 PM, Ralph Goers < >>>> [email protected]> wrote: >>>> >>>>> I haven’t had 5 minutes to spare in 3 days. I will try to look at this >>>>> tonight. >>>>> >>>>> Ralph >>>>> >>>>> On Feb 24, 2016, at 3:46 PM, Gary Gregory <[email protected]> >>>>> wrote: >>>>> >>>>> On Tue, Feb 23, 2016 at 8:23 AM, Gary Gregory <[email protected]> >>>>> wrote: >>>>> >>>>>> I see we now have: >>>>>> >>>>>> org.apache.logging.log4j.core.layout.AbstractStringLayout.Serializer2 >>>>>> >>>>>> Should we >>>>>> deprecate >>>>>> org.apache.logging.log4j.core.layout.AbstractStringLayout.Serializer >>>>>> and reimplement everything in terms of Serializer2, even if objects are >>>>>> allocated? >>>>>> >>>>> >>>>> Thoughts on this? >>>>> >>>>> Gary >>>>> >>>>> >>>>>> >>>>>> Gary >>>>>> >>>>>> On Tue, Feb 23, 2016 at 7:59 AM, Remko Popma <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Layout now extends Encoder so now it has this method: >>>>>>> >>>>>>> encode(LogEvent source, ByteBufferDestination destination) >>>>>>> >>>>>>> PatternLayout implements this method. It delegates the work of >>>>>>> converting the StringBuilder to bytes and writing these bytes into the >>>>>>> ByteBufferDestination to the TextEncoderHelper class. No objects are >>>>>>> created during this conversion. >>>>>>> >>>>>>> The final piece is (Rolling)RandomAccessFileAppender, whose manager >>>>>>> implements ByteBufferDestination. This appender calls the #encode() >>>>>>> methos >>>>>>> on the layout (other managers still call Layout#toByteArray). >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Feb 24, 2016 at 12:47 AM, Mikael Ståldal < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> I cannot really find it. >>>>>>>> >>>>>>>> On Tue, Feb 23, 2016 at 3:59 PM, Remko Popma <[email protected] >>>>>>>> > wrote: >>>>>>>> >>>>>>>>> Yes, that was implemented in >>>>>>>>> https://issues.apache.org/jira/browse/LOG4J2-1274. >>>>>>>>> >>>>>>>>> Please also see the description and discussion in the epic >>>>>>>>> https://issues.apache.org/jira/browse/LOG4J2-1270. >>>>>>>>> >>>>>>>>> Sent from my iPhone >>>>>>>>> >>>>>>>>> On 2016/02/23, at 23:56, Mikael Ståldal <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Do we have any way to convert a StringBuilder to a byte[], without >>>>>>>>> any intermediate String? >>>>>>>>> >>>>>>>>> It seems like org.apache.logging.log4j.core.util.StringEncoder cannot >>>>>>>>> do it. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> [image: MagineTV] >>>>>>>>> >>>>>>>>> *Mikael Ståldal* >>>>>>>>> Senior software developer >>>>>>>>> >>>>>>>>> *Magine TV* >>>>>>>>> [email protected] >>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com >>>>>>>>> <http://www.magine.com/> >>>>>>>>> >>>>>>>>> Privileged and/or Confidential Information may be contained in >>>>>>>>> this message. If you are not the addressee indicated in this message >>>>>>>>> (or responsible for delivery of the message to such a person), you >>>>>>>>> may not copy or deliver this message to anyone. In such case, >>>>>>>>> you should destroy this message and kindly notify the sender by >>>>>>>>> reply email. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> [image: MagineTV] >>>>>>>> >>>>>>>> *Mikael Ståldal* >>>>>>>> Senior software developer >>>>>>>> >>>>>>>> *Magine TV* >>>>>>>> [email protected] >>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com >>>>>>>> <http://www.magine.com/> >>>>>>>> >>>>>>>> Privileged and/or Confidential Information may be contained in this >>>>>>>> message. If you are not the addressee indicated in this message >>>>>>>> (or responsible for delivery of the message to such a person), you >>>>>>>> may not copy or deliver this message to anyone. In such case, >>>>>>>> you should destroy this message and kindly notify the sender by >>>>>>>> reply email. >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> E-Mail: [email protected] | [email protected] >>>>>> <[email protected]> >>>>>> Java Persistence with Hibernate, Second Edition >>>>>> <http://www.manning.com/bauer3/> >>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>>>>> Spring Batch in Action <http://www.manning.com/templier/> >>>>>> Blog: http://garygregory.wordpress.com >>>>>> Home: http://garygregory.com/ >>>>>> Tweet! http://twitter.com/GaryGregory >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> E-Mail: [email protected] | [email protected] >>>>> <[email protected]> >>>>> Java Persistence with Hibernate, Second Edition >>>>> <http://www.manning.com/bauer3/> >>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>>>> Spring Batch in Action <http://www.manning.com/templier/> >>>>> Blog: http://garygregory.wordpress.com >>>>> Home: http://garygregory.com/ >>>>> Tweet! http://twitter.com/GaryGregory >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> [image: MagineTV] >>>> >>>> *Mikael Ståldal* >>>> Senior software developer >>>> >>>> *Magine TV* >>>> [email protected] >>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com >>>> >>>> Privileged and/or Confidential Information may be contained in this >>>> message. If you are not the addressee indicated in this message >>>> (or responsible for delivery of the message to such a person), you may >>>> not copy or deliver this message to anyone. In such case, >>>> you should destroy this message and kindly notify the sender by reply >>>> email. >>>> >>> >>> >> >> >> -- >> [image: MagineTV] >> >> *Mikael Ståldal* >> Senior software developer >> >> *Magine TV* >> [email protected] >> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com >> >> Privileged and/or Confidential Information may be contained in this >> message. If you are not the addressee indicated in this message >> (or responsible for delivery of the message to such a person), you may >> not copy or deliver this message to anyone. In such case, >> you should destroy this message and kindly notify the sender by reply >> email. >> > > > > -- > [image: MagineTV] > > *Mikael Ståldal* > Senior software developer > > *Magine TV* > [email protected] > Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com > > Privileged and/or Confidential Information may be contained in this > message. If you are not the addressee indicated in this message > (or responsible for delivery of the message to such a person), you may not > copy or deliver this message to anyone. In such case, > you should destroy this message and kindly notify the sender by reply > email. >
