This thread interests me somewhat, in particular with respect to the new
paging mechanism and also the backup engine in 0.24 (and I guess trunk).
Is there any info/examples on how to set these up and have a play? Are
they AMQP 0.10/1.0 neutral or do they have dependencies on 1.0?
What I'd quite like is something very similar to jimmy's needs whereby
when a queue has exceeded a threshold messages get redirected to another
queue. TBH I actually implemented something like this using QMF whereby
my QMF application got notified of a queue threshold exceeded QMF event
and when that occurred it did a QMF move message call to move 20% or so
of the messages onto the "alternate" queue (actually my QueueFuse is
largely the same except it purges rather than move messages).
The usage scenarios relate to my need for maximum "sunny day"
performance, so I don't want to have to persist messages on my normal
flow nor do I want to have HA in place and the message replication costs
that entails.
So with a producer broker federated to my main broker from its primary
queue and to my backup broker from its "alternate" queue if my main
broker fails the primary queue fills up and causes queue threshold
exceeded to be triggered thus triggering the messages to be moved to the
alternate queue thence to my backup broker.
A similar mechanism can be used to deliver messages to a "backup engine"
for storage/replay.
This sort of thing sounds quite similar to the replay engine that has
been mentioned, but to be honest I'm not really clear how the replay
engine mechanism needs to be set up. If it's similar in approach it
feels a better model to have the broker do this sort of thing than to
have to put in place an external QMF application. TBH I'd have quite
liked the option to be able to trigger message delivery to the alternate
exchange when being automatically removed from a circular queue - TBH
that kind of feels like the most intuitive interpretation of alternate
exchange delivery in the case of circular queues.
Frase
On 15/07/13 14:59, Gordon Sim wrote:
On 07/15/2013 02:01 PM, Jimmy Jones wrote:
Hi,
I've got a system which can sometimes be a bit bursty, which would
exhaust system memory if the queues were left unchecked. Therefore
I've been using ring queues, which solve the problem quite nicely,
apart from what happens to the "excess" messages. Ideally I'd like to
buffer them to disk and process them at a later, quieter time. I've
been digging around and can see a few options:
1) 0.24 will have flow to disk, which would be perfect but sometimes
my messages are quite big (eg. 10MB) and this requires messages to be
smaller than a page. Is this limitation likely to be removed soon?
The old mechanism (removed in 0.20) was called 'flow to disk'. I
prefer to call the newer feature (to be released with 0.24) 'paging'
or paged queue.
Though it is true that the queues page size must be as large as the
largest message, you can configure that page size. So you could have
just a few pages allowed in memory per queue, but have each page be
10MB (the page size is configured as a multiple of the platform page
size).
As to whether it is likely that the implementation gets updated to
allow a message to span multiple pages... I'd say probably not. To be
able to dispatch the message in parts without having the entire thing
in memory would require a fair bit of work. And without that I don't
see a great advantage over just having bigger pages. (Unless I'm
missing something?)
2) 0.24 allows a "backup engine" to take over a loaded queue
(QPID-4650), but this looks like it'd require a fair bit of legwork
to implement said engine.
3) alternate-exchanges. These look pretty good for my needs, but I
can't seem to get them to work! From reading some documentation, I
thought they'd good with a limit policy of reject - MRG 2
Installation & Configuration guide, 4.8.2 says for an alternate
exchange specified for a queue: "Messages that are acquired and then
rejected by a message consumer". However if I run the test below,
messages only get routed to the alternate exchange when the queue is
destroyed while containing messages, and not when messages are
rejected because the queue is full. Presumably calling
Session::reject would cause it to go to the alternate exchange, but
should a limit policy of reject be the same?
The 'reject' policy is probably a little misleading given the other
use of reject. WHat a 'reject' policy actually does is raise an AMQP
0-10 exception when the limit is reached, which effectively ends the
session. Such messages are never routed to the alternate-exchange of
the exchange or the queue.
Having a client reject rather than accept a message is in fact
entirely different, despite the (confusing) similarity in name.
I have also just added a new policy that causes a queue to self
destruct when it reaches the preconfigured limit. That could possibly
be of interest in conjunction with an alternate-exchange. What would
happen would be that at the point the limit is reached, the queue will
delete itself, re-routing any orphaned messages to the
alternate-exchange if set. The deletion of the queue will result in
any subscribing session being terminated, but won't result in the
publishers session hitting an exception. The issue there however is
that messages published while the queue doesn't exist (i.e. before the
subscriber re-establishes the session and recreates it) would be
dropped (unless of course there were then no matching bindings in
which case it would be rerouted to the exchange's alternate-exchange).
I suspect having spelled that all out it won't be a terribly appealing
path...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
