What acknowledgement mode mode are you using? On Tue, 12 Mar 2019 at 13:22, HADI Ali <[email protected]> wrote: > > Hello, > > In our use case we have polling consumers with a prefetch policy of zero that > issues one credit at a time every few seconds. Between two receive, the > consumer will be attached with zero credit. > Thus, not considering a consumer to be a routable destination until it issues > initial credit would address the problem only for the first message, because > the dispatch will still prefetch possibly expired messages as soon as the > destination is considered routable. > > In this use case we are consuming a few messages per minutes and TTLs are > between 2 to 5 seconds. Concerning the granularity, one second should be > sufficient for us. > > We also noticed that the broker is not forwarding the TTL set at the level of > the queue. Is this an expected behavior? > > Thanks, > Ali > > -----Original Message----- > From: Ted Ross <[email protected]> > Sent: lundi 11 mars 2019 15:32 > To: [email protected] > Subject: Re: Dispatch Router prefetch > > On Fri, Mar 8, 2019 at 9:19 AM Gordon Sim <[email protected]> wrote: > > > On 08/03/2019 2:12 pm, Gordon Sim wrote: > > > On 08/03/2019 12:59 pm, HADI Ali wrote: > > >> Hello, > > >> > > >> We are actually using in our cluster multiple brokers and thus we > > >> need to define the same address on multiple brokers. > > >> For this, we cannot use linkroutes as suggested, but we still need > > >> to have the correct behavior of the TTL in our cluster. > > >> > > >> Is it an option to manage the TTL of the message at the level of > > >> the dispatch router since we have all of the information needed in > > >> the message headers? > > > > > > It doesn't do that at present, but it doesn't seem like an > > > reasonable enhancement to me. > > > > Sorry, meant to say it doesn't seem like an *un*reasonable enhancement! > > > > I'd like to better understand the use case here. We've avoided adding any > kind of TTL support in Dispatch Router up to this point. > > I assume, based on the fact that prefetch-1 didn't solve your problem, that > you have consumers that are attached but don't issue credit for long periods > of time. Is this accurate? > > What is the pattern of your consumers? Do they attach, then later issue > credit to process a message? How many messages per second/minute/hour do > your consumers handle? Do they issue one credit at a time? > > What are the typical TTLs in your messages? How granular does the expiration > need to be (i.e. how accurate of a timer would need to be used to tag each > incoming delivery)? Would one-second granularity be sufficient, or do you > need milliseconds? > > An alternate approach would be to not consider a consumer to be a routable > destination until it issues initial credit. Would this address your problem? > > > > > > >> In Internet Protocol, ipv4 for example, the routers manage the TTL > > >> and discard any expired messages. > > >> > > >> Or make it feasible to have the autolinks propagate the credit > > >> directly from consumers? > > > > > > This isn't really possible when you have autolinks for same address > > > to multiple brokers. If the consumer gives 10 credits, how do you > > > propagate that to two brokers? 5 each? What if they don't both have 5 > > > messages? > > > 10 each? Then you are back to the situation where you have more > > > credit issued at source than the consumer has granted. > > > > > > -------------------------------------------------------------------- > > > - To unsubscribe, e-mail: [email protected] For > > > additional commands, e-mail: [email protected] > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] For > > additional commands, e-mail: [email protected] > > > > > ******************************* > This e-mail contains information for the intended recipient only. It may > contain proprietary material or confidential information. If you are not the > intended recipient you are not authorized to distribute, copy or use this > e-mail or any attachment to it. Murex cannot guarantee that it is virus free > and accepts no responsibility for any loss or damage arising from its use. If > you have received this e-mail in error please notify immediately the sender > and delete the original email received, any attachments and all copies from > your system. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
