Red Hat Bugzilla – Bug 453523
Expandable durable queues
Last modified: 2013-07-22 10:52:00 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).
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.
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.
*** This bug has been marked as a duplicate of bug 709325 ***