It might be problematic atm. But should it be? Paging shouldnt be a problem, it
really should be perf. I think one of the ideas for how we could support
retroactive in future is to have an address in always page mode. This means if
more than anything we should make sure paging is rock solid. Im not against a
change i just want to be sure were able to differentiate for the critical
checker, between something thats not returning e.g. locked up due to bug
(historic reason its there) vs simply its working as it should just working
alot of data... Sent from my Samsung Galaxy smartphone.
-------- Original message --------From: Andy Taylor <[email protected]>
Date: 18/09/2019 19:01 (GMT+00:00) To: [email protected] Subject: Re:
[DISCUSS] Artemis pageIterator.hasNext spends too much time in the case of no
messages matched Yeah, I was thinking more multiple addresses and don't use
selectors. Usingselectors on a topic where there maybe lots of pages messages
is alwaysgoing 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.> > >> > >> > >> > >> > >> > >> >>>>>>>
