That would be same issue if consumers shared a queue and was a consumer side filter, that by consumer would pas lots data. he would hit same issue.
Get Outlook for Android On Wed, Sep 18, 2019 at 1:36 PM +0100, "Andy Taylor" <[email protected]> wrote: 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 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. > > > > > > > > > > > > >
