[ http://jira.qos.ch/browse/LBCORE-128?page=com.atlassian.jira.plugin.system.i... ] 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