<div dir="ltr"><div>On Sat, Jul 5, 2014 at 10:14 AM, Sebastian Gröbler <span dir="ltr"><<a href="mailto:s.groebler@googlemail.com" target="_blank">s.groebler@googlemail.com</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">Hey Logback-Devs,<div><br></div><div>I recently developed an “FileBufferingSocketAppender” for the logback-android (see <a href="https://github.com/tony19/logback-android/pull/57" target="_blank">https://github.com/tony19/logback-android/pull/57</a>) project in order to have a more robust SocketAppender implementation.</div><div>The appender basically buffers events to disk so in case of a crash or connection problem no events are being lost. This is especially an important feature for crash-reporting on android devices.</div><div>After some discussions with Tony we decided that it might make sense to put this Appender in either the logback, logback-contrib or logback-extension project and refer to it from the logback-android project, because the feature it self is not really specific to android.</div><div><br></div><div>The FileBufferingSocketAppender was initially developed before the AbstractSocketAppender got the internal queue to buffer events in memory. After some thinking I found that my FileBufferingSocketAppender is basically not much different to the most recent implementation of the AbstractSocketAppender.</div><div>The only difference is the way the events are being buffered (in-memory vs. on-disk), which I think could be configurable.</div><div><br></div><div>So I am asking the logback developers for their opinion:</div><div><br></div><div>Does it makes sense to make the queue implementation of the AbstractSocketAppender configurable? The default would stay the same, but the user would also be able to either provide his own implementation or choose between in-memory and on-disk.</div><div><br></div></div></blockquote><div><br></div>Hi Sebastian,<div><br></div><div>Since <font face="courier new, monospace">AbstractSocketAppender</font> provides an API for subclasses to specify <font face="courier new, monospace">QueueFactory</font>, I think that would be a great extension point for users to specify a file-backed queue. The default implementation would return <font face="courier new, monospace">LinkedBlockingDeque</font> to maintain the current behavior.</div><div><br></div><div>Then, you could add your <font face="courier new, monospace">FileBackedSocketAppender</font> to logback-contrib or logback-extensions. This appender would extend <font face="courier new, monospace">AbstractSocketAppender</font>, constructed with a custom <font face="courier new, monospace">QueueFactory</font> that returns a file-backed queue (such as <a href="http://square.github.io/tape/" target="_blank"><font face="courier new, monospace">QueueFile</font> from Square Tape</a>).</div><div><br></div><div>Tony</div><div> </div></div></div></div>