How about make hasNext return three states not basic true false,
e.g. return and int where 0 and 1 == current true false, but if returns say 2 then its that more pages to read and needs to spin again. This way if a critical issue with hasNext and processing will still be detected as would hang. But you get positive feedback of still more, and then we know theres not a critical issue just simply lots of data to process through Get Outlook for Android On Wed, Sep 18, 2019 at 8:50 AM +0100, "yw yw" <wy96...@gmail.com> 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. 于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" 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. > > > > > >
