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 <wy96...@gmail.com> Date:
19/09/2019 11:00 (GMT+00:00) To: dev@activemq.apache.org 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 <andy.tayl...@gmail.com>
于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
<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.> >> > <michael.andre.pea...@me.com.invalid> 于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" <wy96...@gmail.com>> > 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.> > >> > >> > >> > >> > >> > >> >>
