Here's some information on dispatch policies: http://activemq.apache.org/dispatch-policies.html
The default is round robin for queues but you can also set priorities. On Sun, Sep 13, 2015 at 5:42 PM, Kevin Burton <bur...@spinn3r.com> wrote: > 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> >
