Thanks for suggestions. I will provide a PR soon :) michael.andre.pearce <[email protected]> 于2019年9月20日周五 上午8:21写道：
> This sounds like a reasonable pattern to me. Especially in an event based > architecture.As i noted in the other email. My main concern is being able > to keep the ability to detect dead or live locks (code issues historically) > which is what critical analyser is there for vs its just processing data.. > thus my one idea of having hasNext being multi state return not just > boolean Sent from my Samsung Galaxy smartphone. > -------- Original message --------From: yw yw <[email protected]> Date: > 19/09/2019 11:00 (GMT+00:00) To: [email protected] Subject: Re: > [DISCUSS] Artemis pageIterator.hasNext spends too much time in the case of > no messages matched Thanks, it's indeed a publish-subscribe pattern in our > case. There is atopic to which changing information of products is sent and > severalapplications are interested in receiving. There is some bug dealing > withproduct info in one application that needs to be fixed and > redeployed,which is the most common case we've met.Andy Taylor < > [email protected]> 于2019年9月18日周三 下午8:36写道：> If you are dealing with > subscribers not being connected for very long> periods of time I would > question your choice of using topics in the first> place. Maybe use a > different topology, 1 address/queue per consumer for> instance.>> On Wed, > 18 Sep 2019 at 08:50, yw yw <[email protected]> wrote:>> > Thanks for the > reply. I'm not asking to remove critical check. As you> said,> > we can > just increase timeout or log the failure. Our concern is the> second> > > problem with starvation on other queues. It's unacceptable for near> > > real-time processing of other subscribers to the topic.> >> > < > [email protected]> 于2019年9月18日周三 上午12:58写道：> >> > > So > the critical check is there to avoid issues where stuff takes too> long> > > > on the critical path. It was off the back of some major production> > > issues.> > >> > >> > >> > >> > > I would be hesitant to relax / remove it.> > > >> > >> > >> > >> > > If you know in your broker things take longer you > could always> configure> > > to increase the critical timeout.> > >> > >> > > >> > >> > > Get Outlook for Android> > >> > >> > >> > >> > >> > >> > >> > > > On Tue, Sep 17, 2019 at 11:00 AM +0100, "yw yw" <[email protected]>> > > wrote:> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > > Hi, All> > >> > > > There is something about pageIterator scanning that haunts us over a> > long> > > period of time since we use artemis.> > >> > > The use case is > common:> > >> > > E.g. There is a topic with two queues: q1 and q2. Due to > some reasons> > such> > > as a bug in the business logic, the clients stop > from receiving from q1> > and> > > following messages sent to the topic are > not routed to q1 again(the> > clients> > > don't want to receive messages > until they get back online). After a few> > > days, the clients are backup > starting to consume messages from the> queue.> > > At this point, calling > hasNext will scan page files until finding> > matching> > > > messages(actually no messages matched before this point and dozens of> GB> > > > page files are written during business down time). This will lead to> > some> > > problems:> > > 1. Critical analyzer will be triggered, i.e. > CRITICAL_CHECK_DEPAGE. In> > our> > > setup, the process would be > terminated.> > > 2. hasNext might be called in queue's executor, as we > know, the> executor> > is> > > shared by all the queues binding to the > address, this would cause> > > starvation on other queues resulting no > messages delivered lasting for> a> > > few minutes.> > >> > > One of the > alternative approach i can think is to add some timeout for> > > > hasNext/next. If timeout happens, it will be scheduled later to avoid> > > > problems above mentioned. Does anybody have any opinion on this?> > >> > > > Thanks in advance.> > >> > >> > >> > >> > >> > >> >>
