qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kim van der Riet <kim.vdr...@redhat.com>
Subject RE: Journal Full Error
Date Fri, 24 Jul 2009 20:10:20 GMT
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.


Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org

View raw message