[logback-dev] [JIRA] Commented: (LBCORE-128) Please support implementation of binary log files in RollingFileAppender/FileAppender

Joern Huxhorn (JIRA) noreply-jira at qos.ch
Thu Feb 18 10:04:34 CET 2010


    [ http://jira.qos.ch/browse/LBCORE-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11540#action_11540 ] 

Joern Huxhorn commented on LBCORE-128:
--------------------------------------

I just checked it out and removed both callstack and exception info from the events before serializing them using protobuf.

206b Protobuf uncompressed (76,908.29 ops/s)
150b Protobuf compressed (5,007.15 ops/s)
359b Streaming Java serialization (44,939.78 ops/s) like SocketAppender is currently performing, i.e. without creating new ObjectOutputStream for every event.
1.49kib Java serialization uncompressed (39,169.6 ops/s, new OOS for every event) 
742b Java serialization compressed (3,533.51 ops/s, new OOS for every event)

Compresses reasonably well, I think.

The way an encoder decorates a stream is, imo, an implementation detail that shouldn't be relevant for the appender.

I don't say that every encoder must work that way, I'd just like to be able to implement an encoder that is working that way (other examples include signing and/or encrypting events).

I could implement my encoder the way I like by implementing a no-op decorate, so this won't be a problem for me. I'm simply not really sure if it's a good idea.

> Please support implementation of binary log files in RollingFileAppender/FileAppender
> -------------------------------------------------------------------------------------
>
>                 Key: LBCORE-128
>                 URL: http://jira.qos.ch/browse/LBCORE-128
>             Project: logback-core
>          Issue Type: Improvement
>          Components: Appender
>    Affects Versions: 0.9.17
>            Reporter: Joern Huxhorn
>            Assignee: Ceki Gulcu
>
> This was discussed briefly at http://marc.info/?l=logback-dev&m=124905434331308&w=2 and I forgot to file a ticket about this.
> Currently, RandomFileAppender => FileAppender => WriterAppender is using the following method in WriterAppender to actually write the data:
> protected void writerWrite(String s, boolean flush) throws IOException
> Please add an additional method like
> protected void writerWrite(byte[] bytes, boolean flush) throws IOException
> to write to the underlying stream directly.
> writerWrite(String, boolean) could call that method after performing the transformation internally, making this change transparent for the rest of the implementation.
> Using a binary format for logfiles could have tremendous performance impact as can be seen here: http://sourceforge.net/apps/trac/lilith/wiki/SerializationPerformance

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the logback-dev mailing list