Perhaps a work-around would be to create a garbage-service. Ie. a
services that pops off all messages not needed by the consumer to
/dev/null? Though you probably don't know which messages are not needed
by the subscriber since you don't know which subscribers you will
have... Perhaps you could create an algorithm that does something like
"if the consumer is up and the message is older than xxx time" pop it
off?
On Mon, 1 Nov 2010 10:25:40 +0000, "Maciej Rakowicz"
<[email protected]> wrote:
in case of selectorAware=true and consumer down, what happens to
those messages? are they discarded? Is there anything sent to one of
the advisories? I can't seem to find it anywhere.
On 1 Nov 2010, at 09:48, Maciej Rakowicz wrote:
I guess, only if we keep downtimes short enough so 'matched'
messages don't expire and big enough maxPageSize or something to keep
matched messages consumed.
Does anyone know if this (i.e. AMQ-3004) is going to be worked on in
the near future?
m.
On 1 Nov 2010, at 09:32, Gary Tully wrote:
Message expiry may help in the short term, set a time to live on
the
messages such that the built up unmatched messages expire and are
removed.
On 1 November 2010 09:20, Maciej Rakowicz <[email protected]>
wrote:
All,
amq 5.4.0. jdk 1.6
Scenario:
broker persistence=true, selectorAware=false
Virtual Topic with say one queue. There is a consumer A connected
to that
queue with a selector. All works fine. Consumer A dies, messages
pile up,
consumer A starts back up, missed messages are redelivered. You
can easily
verify that queue receives all posted messages while consumer's
down.
Now, adding consumer B, since selectorAware=false and consumer B
uses an
exclusive selector messages sent to consumer A are not consumed by
consumer
B. All good save the fact that all unmatched messages end up
polluting
consumer's B queue. All according to the documentation.
Flipping selectorAware to true solves one problem but introduces
another
(way more important in my setup). Unmatched messages won't pile up
on
consumer's B queue which is fine. However, if consumer A dies they
are not
sent to consumer's A queue (disappearing after reaching the topic
- I dunno
where they go) hence disabling any missed message delivery on
consumer's A
startup.
I there any way around it? I really need to handle all missed
messages with
no exception. At the same time I cannot allow stacking up messages
in each
and every queue although they are not matched.
Btw. I do not have a list of consumers in advance, the
subscription is fully
dynamic, although since broker runs persistence, once subscribed I
do have
an idea of who's subscribed even if connection is currently down.
I would appreciate any hints.
mac
-- http://blog.garytully.com
http://fusesource.com
