I believe the *prefetch* for queues and topics actually work this way: If you *have not set* anything on the client, i.e. using the default, then it will be controlled by the server. You may thus override it on the client (with a prefetch policy on the connection factory), but get defaults from server (with the prefetch policies set there). At least this is how I've come to understand the documentation.
This broker redelivery solution/implementation actually feels like a hack; Not being present from the initial design, and then hacked on later. But while researching this, I found that I can achieve what I want by using connectionFactory.setNonBlockingRedelivery(true). Who would have known.. Thanks, Kind regards, Endre. On Wed, Mar 9, 2022 at 2:01 PM Tim Bain <tb...@alumni.duke.edu> wrote: > 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. > > >
