Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: Sandy Pratt <prattrs@adobe.com>
To: "users@qpid.apache.org" <users@qpid.apache.org>
CC: Jason Copeland <copeland@adobe.com>
Date: Fri, 24 Jul 2009 11:31:34 -0700
Subject: RE: Journal Full Error
Thread-Topic: Journal Full Error
Thread-Index: AcoMikIUrc6LsqcLRNScUtBkq1L5IwAAP//w
Message-ID: 
 <A0B699C30D50C84883E79752AEA74B881A2DF30115@NAMBX01.corp.adobe.com>
References: 
 <A0B699C30D50C84883E79752AEA74B881A2DF30114@NAMBX01.corp.adobe.com>
 <4A69FB07.2020800@redhat.com>
In-Reply-To: <4A69FB07.2020800@redhat.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Thanks for the answers, Gordon.  Comments inline, if Outlook cooperates.

> -----Original Message-----
> From: Gordon Sim [mailto:gsim@redhat.com]
> Sent: Friday, July 24, 2009 11:19 AM
> To: users@qpid.apache.org
> Cc: Jason Copeland
> Subject: Re: Journal Full Error
>=20
> Sandy Pratt wrote:
> > I'm experimenting with the qpidd broker supplied with Fedora 10
> (qpidd (qpidc) version 0.5 - the install should be up to date as of
> yesterday).
> > Basically, I'm having a problem where I've been able to enqueue
> enough messages that my journal is full and I can't start the broker
> because of this.  This is contrary to my understanding of how
> persistent queues were supposed to work, in a number of ways:
> >
> > 1) I thought producers were not allowed to commit messages past the
> 80% full point.
>=20
> That was be understanding also. Kim any thoughts on how the journal
> could allow itself to get into a state where it can't be recovered?
>=20
> > 2) I thought the flow-to-disk policy would result in excess messages
> being accepted into a slower interim storage, not being rejected or
> causing the broker to crash.
>=20
> Transient messages are stored in a different storage if they exceed the
> defined queue policy limit, and that grows as needed. Persistent
> messages however are written to the journal regardless of whether the
> queue policy limit which currently has a fixed size that must be
> defined
> up front.
>=20
> >
> > 3) It appears as though I was able to crash the broker and cause the
> apparent loss of acked messages simply by sending the broker too many?
>=20
> Could you give a bit more detail on this point?


[Sandy Pratt]=20
I was hoping that regardless of whether I could write to the queue, I would=
 still be able to start the broker and read them, or get them out somehow -=
- because having committed the messages to the broker, that might well be t=
heir sole home.  If I can't get them out, then I've lost them.  Is there a =
procedure for extracting messages from a full journal?


[Sandy Pratt] snip...

> > I can sort of understand this, although it means flow-to-disk is not
> functioning for my queue, I suppose.
>=20
> As above, the persistent messages would always be written to the
> journal
> and it has a fixed size.
>=20
> The 'flow-to-disk' policy is probably confusingly named and
> inadequately
> described. It really just releases the message content from memory when
> a queue hits a particular limit; where those messages are durable
> anyway
>   nothing else is done. If however the messages are transient they are
> stored elsewhere and can then be reloaded for delivery.


[Sandy Pratt] Understood, thank you.  Flow-to-disk is a property of non-per=
sistent messages/queues, not persistent ones.=20


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