Redelivery of messages previously consumed.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Redelivery of messages previously consumed.

fenbers
This post was updated on .
I'm reposting this with updated information.

I'm setup to use durable Topics with retroactive=true.  

My application consumes messages, which lights up certain status indicators.  While this works fine, I have a problem in that if the user exits and restarts my application, sometimes the messages are redelivered and sometimes they are not.  I always want all non-expired messages to be redelivered upon relaunch, no matter how many times the app is relaunched, but this behavior is inconsistent.

If redelivery NEVER occurs, I'd look at this as a configuration mistake, but redelivery does occur about 50% of the time.  I cannot figure out why this is inconsistent.  Does anyone have ideas of what I can try?  I'm using 5.14.2.  Might there be a way, programmatically, for the app to manually request a redelivery of all unexpired messages (in the order of creation), say, through a "refresh" button -- even if they have been previously consumed?
Mark
Reply | Threaded
Open this post in threaded view
|

Re: Redelivery of messages previously consumed.

Tim Bain
There's no mechanism to request that the broker send you everything it has;
if that is going to happen, it happens when the client connects.

In your testing, are you saying that if topic T has messages A, B, and C
that have not yet been consumed by offline durable consumer C1, and
consumer C2 connects and disconnects repeatedly, C2 will sometimes get A,
B, and C, and sometimes will get nothing or some subset of A, B, and C? Can
you please describe in a little more detail exactly what behavior you see?
In particular, redelivery will happen only for messages that are still
unconsumed for at least one other subscription (because once all
subscriptions have consumed it, the broker discards the message), so please
be very specific about which messages are in the topic and which consumers
have consumed which messages at which point.

Tim

On Feb 13, 2017 12:06 PM, "fenbers" <[hidden email]> wrote:

> I'm reposting this with updated information.I'm setup to use durable Topics
> with retroactive=true.  My application consumes messages, which lights up
> certain status indicators.  While this works fine, I have a problem in that
> if the user exits and restarts my application, sometimes the messages are
> redelivered and sometimes they are not.  I always want all non-expired
> messages to be redelivered upon relaunch, no matter how many times the app
> is relaunched, but this behavior is inconsistent. If redelivery NEVER
> occurs, I'd look at this as a configuration mistake, but redelivery does
> occur about 50% of the time.  I cannot figure out why this is inconsistent.
> Does anyone have ideas of what I can try?  I'm using 5.14.2.  Might there
> be
> a way, programmatically, for the app to *manually* request a redelivery of
> all unexpired messages (in the order of creation), say, through a "refresh"
> button -- even if they have been previously consumed? Mark
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/Redelivery-of-messages-previously-consumed-tp4721929.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Reply | Threaded
Open this post in threaded view
|

Re: Redelivery of messages previously consumed.

fenbers
OK.  The client app has a durable consumer C has connected to Topic T, and while it is active, messages X, Y, and Z are eventually delivered by the broker and consumed by C.  Then, C disconnects and then reconnects (sometimes immediately).  When C reconnects, sometimes messages X, Y, and Z are redelivered (and consumed) and sometimes the messages X, Y, and Z seemingly are not redelivered even though other messages U, V, and W are delivered and consumed properly.

In addition, the same client app has a second durable consumer B connected to Topic S.

The mystery is why X, Y, and Z are not always redelivered upon C's reconnection to T, while all messages to Topic S are redelivered upon reconnection of consumer B.  (To clarify, no messages at all are redelivered to C.)  Even stranger, on occasion X, Y, and Z (to clarify, all messages) do sometimes get redelivered after a handful of disconnects/reconnects, but not always.  There are always some offline subscriptions D and E, and so the messages X, Y, and Z should still be in the broker until the message expires.  In my case, X, Y, and Z are not yet close to expiring when this occurs.

There is an overwhelming amount of information in the log files, even without the highest levels of logging.  Is there something specific in the log that can tell me anything about the fates of messages X, Y, and Z?  Are they still in the broker?  If so, why aren't they redelivered on a reconnect?  If not, what happened to them?  Or maybe the log will say something about the consumer C rejecting redelivery for some reason?  

To be honest, I am overwhelmed by the logging (most of which I don't understand) for that to be too helpful in my investigation unless I know specifically what to search for.
Mark