Yeah, I was thinking more multiple addresses and don't use selectors. Using selectors on a topic where there maybe lots of pages messages is always going to be problematic.
On Wed, 18 Sep 2019, 16:40 , <[email protected]> wrote: > 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. > > > > > > > > > > > > > > > > > > > > > > > > > >
