Bug 453523 - Expandable durable queues
Expandable durable queues
Status: CLOSED DUPLICATE of bug 709325
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp (Show other bugs)
1.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kim van der Riet
MRG Quality Engineering
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-01 03:53 EDT by Gordon Sim
Modified: 2013-07-22 10:52 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-22 10:52:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gordon Sim 2008-07-01 03:53:43 EDT
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 12:27:35 EDT
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 14:04:47 EDT
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 10:52:00 EDT

*** 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.