I don't know this code nor the history behind the design decision, but this behavior is what I would have expected.
What you're doing (if server side, then no client side) is probably the typical case, and in that case it would be beneficial to have it get defaulted automatically. But I'm not convinced that it's invalid to have non-zero values for both, and what you're proposing is more complicated to implement (have to make the protocol pass the server value to the client, then have to track whether the client explicitly specified a value and override it only if not specified explicitly, and have to document that clients using the default value may find the value they're using automatically changes based on server configuration that might change later so if they want to be sure of their behavior then they should set the value explicitly and not use the feature). So while what you hoped for is possible, the current behavior is what I'd have expected. Tim On Tue, Mar 8, 2022, 1:49 PM Endre Stølsvik <en...@stolsvik.com> wrote: > Hi! > > Trying to set up broker redelivery, and was wondered really much on how > that interacts with the default client side redelivery. > > And now I seem to know, and this was pretty strange: You get both?! > > So, with setMaximumRedeliveries(2) on the broker, and without doing > anything on the client, literally just setting up an > ActiveMQConnectionFactory, I seem to get 7 attempts, then new 6 attempts, > then 6 attempts, then DLQ. > > Breakpointing in the RedeliveryPlugin.java:143, this is confirmed: After > the first 7 attempts, this breakpoint is hit, and the redeliveryCount == 0. > After the next 6, new hit, redeliveryCount == 1, and then finally after 6 > more, redeliveryCount == 2 and DLQ. > > Is this really to be expected? Do I actually need to set 0 redeliveries on > the client connection to get proper broker controlled redelivery? I had > hoped that the server-side setting of redelivery would override the client. > > Thanks, > kind regards, > Endre. >
