On Fri, 2009-07-24 at 12:45 -0700, Sandy Pratt wrote: > [Sandy Pratt] > > That's a clue. I was using messages of about 21 bytes previously, so > maybe there were a few of those hanging out in the journal still. I > didn't explicitly empty the queue when I changed the message size. > > If you start the broker with a --log-enable info+ parameter, then the journal will print out the number of recovered records in the log when it recovers the old journal files. This will let you see how many (if any) previous records are in play.
However, for this to create the scenario I described, your application will need to dequeue all these messages - and the number of dequeues must be great enough to fill the 20% space. Leaving orphaned records undequued in the journal will definitely block the journal, but should not defeat the enqueue threshold test. Another record that is not subject to the test are transactional commit and abort records. For this to be significant, an application would need to open thousands of transactions, one for each enqueue, and keep them open until just below the enqueue threshold. If all these commits are then made at once, the journal could be filled. However, this seems an unlikely scenario. Looking at the journal files will quickly give me an idea of the scenario which lead up to the full condition (but not necessarily the reasons) - or at least rule out some of these hypotheses. Kim --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
