I believe that setting prefetch=0 only changes how that message gets dispatched to the first consumer (pull vs. push); once it's there, I wouldn't expect the broker's behavior w.r.t. that dispatched message to change (and indeed you say it didn't). But as you say, closing the connection returns all dispatched messages to the broker so they can be dispatched to another consumer.
I haven't looked at the redelivery code, but I wonder if the logic is actually to round-robin between the consumers rather than to redeliver them all to the consumer that had them, in which case it might be hard to tell what the behavior is when you're only publishing one message. If you set prefetch=4 and publish four messages instead of one with two connected consumers (so your first consumer gets two of them initially), do you get both messages redelivered to the first consumer or only one? Tim On Sep 12, 2015 11:21 AM, "Kevin Burton" <bur...@spinn3r.com> wrote: > AH ! Good point about the prefetch policy. That always confusing because > it’s a way for messages to kind of be delivered but hidden. > > Anyway. Setting prefetch to zero doesn’t resolve it.. But closing the > second connection DOES… > > So I think this is how it works.. which I couldn’t find documented anywhere > (but I’m sure I’m missing it ) > > - Prefetch is an issue because you shouldn’t assume it’s going to be sent > to a specific connection unless prefetch is 0… > > - The redelivered message is always sent back to the consumer that > originally consumed the message , if it’s still open. I wonder if this is > done for performance reasons. The only way this is not the case is if that > consumer goes away … then it’s redelivered to another host. > > > On Sat, Sep 12, 2015 at 9:49 AM, Christopher Shannon < > christopher.l.shan...@gmail.com> wrote: > > > Your problem is you are always creating a new consumer in your consume() > > method but never closing it. So the consumer is sticking around and > > hanging onto messages in prefetch. You either need to reuse your message > > consumer (call receive() on the same open consumer after rollback because > > it's getting the message again in prefetch) or close it and use a > different > > consumer. You might also be able to set prefetch to 0 to get it to work. > > > > I took your code and modified it both ways to show each strategy: > > > > https://gist.github.com/cshannon/45d573fabeba733c6bb6 > > https://gist.github.com/cshannon/64b8f790f9b57269ae45 > > > > On Fri, Sep 11, 2015 at 7:14 PM, Kevin Burton <bur...@spinn3r.com> > wrote: > > > > > OK. > > > > > > For the life of me I can’t get this to work. > > > > > > https://gist.github.com/burtonator/eb7a70e1750080ca621e > > > > > > Basically I want to call rollback() so that a message is retries later. > > > This way if there’s a transient but like a database connection failing > it > > > gets retried (but of course uses the retry policy). > > > > > > The problem is that it just doesn’t work. > > > > > > I tried creating too ‘clients’ whereby each has its own client ID. > That > > > doesn’t work either. > > > > > > I went through the tests in ActiveMQ and didn’t see anything obvious > > > there. I must be missing something super obvious…. > > > > > > Any thoughts? > > > > > > -- > > > > > > Founder/CEO Spinn3r.com > > > Location: *San Francisco, CA* > > > blog: http://burtonator.wordpress.com > > > … or check out my Google+ profile > > > <https://plus.google.com/102718274791889610666/posts> > > > > > > > > > -- > > Founder/CEO Spinn3r.com > Location: *San Francisco, CA* > blog: http://burtonator.wordpress.com > … or check out my Google+ profile > <https://plus.google.com/102718274791889610666/posts> >
