JMS guaranteed delivery is achieved by sending the message to the JMS server and then writing it to disk similar to what Flume does. Doing it locally before sending is an order of magnitude faster. At least that is the difference between the remote and embedded Flume appenders.

Ralph

On Mar 2, 2013, at 4:00 PM, Gary Gregory <garydgregory@gmail.com> wrote:

Sounds like a job for a JMS provider like ActiveMQ. 

Gary

On Mar 2, 2013, at 18:50, Ralph Goers <ralph.goers@dslextreme.com> wrote:

What I am looking for is simply a Queue interface that persists log events to disk such that control can be returned to the caller immediately after writing to the queue and even if the JVM crashes it is guaranteed that the log event will be delivered even after a restart.  I've found some code that lets me do that with Berkeley DB for Java. I know that that code base is quite a bit newer than Berkeley DB itself and I haven't ever heard discussions from anyone using it to know what kinds of problems there may be. All the uses for HSQL I've ever seen basically say not to use it for production stuff, although I don't know why. Plus, I really don't need a full RDBMS to implement a queue.

Ralph

On Mar 2, 2013, at 12:00 PM, Gary Gregory wrote:

If you are looking for a Java embeddable database, I've used H2 for unit testing a JDBC piece instead of using heavier databases like MySQL, Oracle, MSSQL and so on.

G


On Sat, Mar 2, 2013 at 12:15 PM, Ralph Goers <ralph.goers@dslextreme.com> wrote:
Does anyone have experience using Berkeley DB for Java?  I am looking at creating something similar to the embedded Flume appender using Berkeley DB as the "file channel" so that I don't have to bring in all the Flume dependencies and the socket connection to Flume can be done asynchronously.  In effect, I would be using Berkeley DB as the queue between the client and the asynchronous portion of the Appender.

I'd like to know if I am opening myself up for problems in doing this so if anyone has experience with using it I'd like to know about them.

Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org




--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory