title: Is JMS the answer to the need for a persistent blocking queue?
body: <p>I'm creating a library that consists of a Log4J appender that asynchronously sends events to a remote server.  When a log statement is made, the appender will asynchronously record the event into a local queue which a pool of consumers will then retrieve and send to the remote.</p>
  
  <p>The completely in-memory solution would be to create a BlockingQueue which would handle the concurrency issue.  However, I'd like for the queue to be persisted so that if the remote server is not available I don't grow the queue unbounded or start to discard messages in the case of a bounded queue.</p>
  
  <p>I was thinking of using an embedded H2 database to store the events locally and then use a polling mechanism to retrieve events and send to the remote. I would much rather use a BlockingQueue than to poll a database table.</p>
  
  <p>Is JMS the answer?</p>
  
  <p>EDIT:</p>
  
  <p>If JMS is the answer, and it seems to be going that way, does anyone have recommendations on a lightweight, embeddable JMS solution that can be configured to only accept messages in-process? In other words, I do not want to, and possibly will not be allowed to, open up a TCP socket on which to listen. </p>
  
  <p>EDIT:</p>
  
  <p>I've got ActiveMQ embedded now and it seems to be working. Thanks all.</p>