Bug 453523

Summary:	Expandable durable queues
Product:	Red Hat Enterprise MRG	Reporter:	Gordon Sim <gsim>
Component:	qpid-cpp	Assignee:	Kim van der Riet <kim.vdriet>
Status:	CLOSED DUPLICATE	QA Contact:	MRG Quality Engineering <mrgqe-bugs>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	1.0	CC:	cctrieloff, freznice, jross
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-07-22 14:52:00 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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