I’m going to try to get someone to try your suggestions at site tomorrow.
Regarding your question, yes, the subscriber is a server that is started
before the producers and never restarted. Does it matter that there are
multiple producers to the topic. Also it’s a very low volume topic, there
is lo
The number of producers and the message volume should both be irrelevant.
Though of course if there's a bug, all bets are off.
On Apr 8, 2018 5:53 AM, "Lionel van den Berg" wrote:
I’m going to try to get someone to try your suggestions at site tomorrow.
Regarding your question, yes, the subscri
Good news, it’s our bug. We have some logic that is automatically cleaning
up inactive consumers, that logic was supposed to be turned off.
On Mon, 9 Apr 2018 at 12:39 am, Tim Bain wrote:
> The number of producers and the message volume should both be irrelevant.
> Though of course if there's a
I was hoping you'd say that, because if the broker was randomly failing to
deliver a couple of messages out of a huge number, that wasn't going to be
a lot of fun to track down. So I'm glad you figured it out, for both our
sakes.
Tim
On Sun, Apr 8, 2018, 6:58 PM Lionel van den Berg wrote:
> Goo
As you say, I'm using KahaDB.
> You asked whether subscriptions would be on the new master, and the answer
> depends on whether the subscription was durable. If it was a durable
> subscription, the subscription information is persisted and the
> subscription will be in the same state on the new
I’m glad it was my code too, and expected it to be. At least now I have
some additional ideas for debugging I’m the future.
On Mon, 9 Apr 2018 at 12:17 pm, Tim Bain wrote:
> I was hoping you'd say that, because if the broker was randomly failing to
> deliver a couple of messages out of a huge nu
The documentation you linked to is for the AMQ message store, not the
KahaDB message store. So if you're using KahaDB as you say, then the page
you linked to is irrelevant.
KahaDB behaves as I described. You only risk losing messages that have not
yet been accepted (i.e. you don't risk losing anyt
Hi Tim,
Thanks for your suggestions.
Saying that, moving to ActiveMQ Artemis would be the ideal option. I'm also
not sure whether all the features being used by us (camel routes are used to
produce and consume JMS messages) with ActiveMQ 5.14.4 will be available in
ActiveMQ Artemis 2.5.0.
>From
