Hi,
@Chris, following the process, I would need help of a PMC to merge the
website PR. Would you have time later today (PR is on the way) ? I will
send the announcement email when website is ok.
Regards
JB
On 16/09/2019 15:11, Jean-Baptiste Onofré wrote:
> Hi guys,
>
> just to let you know
Hi Everyone
Thanks for all the feedback. I have put my producer and consumer code and
broker.xml file on a public GitHub repo:
https://github.com/brianr82/artemistesting.git
Please see my replies below.
My reply to Arthur's questions:
> - First, reproduce the problem outside of
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 , wrote:
> That would be same issue if consumers shared a queue and was a consumer
> side
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"
wrote:
If you are dealing with subscribers not
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
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.
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日周三
