It seems to be fixated to the first consumer that had a message? I think ideally it would be first come first serve.
Setting prefetch=0 doesn’t seem to have any impact. I *kind* of think this is why the redelivery is set on the client but I might be wrong. It seems weird to me to set the redelivery policy on the client. This seems something that could/should be enforced on the server. Of course if you control all the clients its about the same thing. It’s completely possible to have an unbalanced cluster. This is why queueing theory rocks. Because this way if the original consumer that first processed the message (and failed) is now overloaded, another, less busy one can come in and handle it. I might do some more testing to just verify my theory. Maybe use a set of headers detailing which consumers are processing the messages. Would love to to be proven wrong here. On Sun, Sep 13, 2015 at 8:22 AM, Tim Bain <tb...@alumni.duke.edu> wrote: > 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> > > > -- 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>
