Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 453523 - Expandable durable queues
Summary: Expandable durable queues
Status: CLOSED DUPLICATE of bug 709325
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp
Version: 1.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Kim van der Riet
QA Contact: MRG Quality Engineering
Depends On:
TreeView+ depends on / blocked
Reported: 2008-07-01 07:53 UTC by Gordon Sim
Modified: 2013-07-22 14:52 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-07-22 14:52:00 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Gordon Sim 2008-07-01 07:53:43 UTC
Currently queues have a fixed limit and if a publisher fills it to that limit an
error occurs. It would be preferable to allow the queue to grow as needed
(within policy and resource constraints).

Comment 1 Frantisek Reznicek 2008-10-31 16:27:35 UTC
Vague description ... it mentions a limit, but how is that limit
configured?  How do we push or try to cross this limit?  Need to write test
program? Putting NEEDINFO flag.

Comment 3 Kim van der Riet 2010-08-11 18:04:47 UTC
Answering Frantisek's NEEDINFO:

The store journals are fixed in size from creation. If a user enqueues more than this fixed size can hold, then an enqueue threshold error occurs, closing the connection. This requires that the user accurately estimate the worst-case size needed to contain persistent messages in each queue.

A feature could be added to the store that would allow additional files to be inserted into the store when it gets close to being full. This feature would be known as "auto-expand". However, the user would still need to correctly size the journal as allowing auto-expand to perform the expansion would be bad for performance. Using auto-expand should be regarded as a fall-back strategy rather than a reason to not size the store correctly in the first place. It would allow the broker to keep running when it would otherwise stop in cases where the store gets fuller than anticipated.

The amount by which the store could expand would be set by the user in the config file or on the command line. The user can limit the largest size the store can reach through auto-expand before an enqueue threshold is finally returned. The number of files would still be constrained by the current maximum number of files, ie 64.

For example, a user could set the store to 12 files, but allow auto-expand to go no higher than 16 after which it would fail through the normal enqueue threshold error.

This feature is planned, but not yet implemented.

Comment 5 Justin Ross 2013-07-22 14:52:00 UTC

*** This bug has been marked as a duplicate of bug 709325 ***

Note You need to log in before you can comment on or make changes to this bug.