Yes, please do. Jira is the right place to capture the requirements for this feature.
-Ted On Tue, Mar 19, 2019 at 9:27 AM HADI Ali <[email protected]> wrote: > Hello, > > Concerning handling the TTL at the level of the Dispatch Router, should we > open a Jira ticket to track the issue and continue the discussion ? > Depending on the priority of this issue on both sides, we are open to > contribute if needed. > > Regards, > Ali > > -----Original Message----- > From: HADI Ali > Sent: mercredi 13 mars 2019 11:14 > To: [email protected] > Subject: RE: Dispatch Router prefetch > > We support both, it depends on the use case (we have multiple services > using the messaging). > > -----Original Message----- > From: Robbie Gemmell <[email protected]> > Sent: mardi 12 mars 2019 15:15 > To: [email protected] > Subject: Re: Dispatch Router prefetch > > 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] > > ******************************* > 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. >
