Re: Replicated Message Store for ActiveMQ

[SubashKunjupillai]

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 community perspective can some one comment on the feature compatibility
and durability of Artemis?

Regards,
Subash Kunjupillai



-
Subash Kunjupillai
--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: Shared File System Master Slave

[Tim Bain]

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 anything). If I recall
correctly, the only thing that's flushed to disk periodically is the index,
and that can be rebuilt from the raw journal files so there's no risk of
data loss, just a slower broker startup.

Tim

On Sun, Apr 8, 2018, 10:06 PM norinos  wrote:

> 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 master, even if the
> > client doesn't immediately reconnect. If the subscription is not durable,
> > then it will be recreated when the client reconnects to the new master,
> so
> > any messages that were unconsumed at the time the original master went
> > down
> > and any messages sent before the client reconnects will be lost for that
> > subscriber.
>
> I'm using durable subscription.
> So, I understand that clients can receive the message without problems
> when switching from master to slave.
>
>
> Please tell me a little more.
>
> ActiveMQ insert cache index into the reference store for performance at
> checkpoint interval.
>
> If master goes down, it seems that chache index can not insert.
> So reference store is not up-to-date.
>
> In this case, if I startup up ActiveMQ, Is the reference store updated at
> the start-up phase?
>
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>

Re: Message appears to be sent but not received

[Lionel van den Berg]

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 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:
>
>> 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 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 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 lots of data on other topics on the same connection.
>>>
>>>
>>>
>>>
>>> On Sun, 8 Apr 2018 at 1:43 am, Tim Bain  wrote:
>>>
>>> > I'd suggest you use a JMX viewer such as JConsole, and navigate through
>>> the
>>> > org.apache.activemq MBeans to find the subscription in question. On the
>>> > Attributes page under the subscription, you'll see counts for the
>>> number
>>> of
>>> > messages enqueued and dequeued.
>>> >
>>> > If those don't match, it means your messages are not getting delivered
>>> to
>>> > the subscriber. (Could they be expiring before they can be consumed?)
>>> >
>>> > If they match, but are lower than the number you sent to the topic
>>> while
>>> > the consumer was subscribed, we'll have to dig deeper.
>>> >
>>> > Also, I understand from your response that these consumers have been
>>> > subscribed and connected the entire time the messages were being sent.
>>> Is
>>> > that what you're saying?
>>> >
>>> > Tim
>>> >
>>> > On Fri, Apr 6, 2018 at 7:11 AM, Lionel van den Berg >> >
>>> > wrote:
>>> >
>>> > > Non-durable an using the same connection as other topics that are
>>> still
>>> > > working. No filters.
>>> > >
>>> > >
>>> > > On Fri, 6 Apr 2018 at 11:03 pm, Tim Bain 
>>> wrote:
>>> > >
>>> > > > Are the topic subscriptions durable or non-durable? If the latter,
>>> were
>>> > > the
>>> > > > clients disconnected at the time the messages in question were
>>> sent?
>>> > > >
>>> > > > Also, do the subscribers in question use any selectors?
>>> > > >
>>> > > > Tim
>>> > > >
>>> > > > On Fri, Apr 6, 2018, 12:26 AM Lionel van den Berg <
>>> lion...@gmail.com>
>>> > > > wrote:
>>> > > >
>>> > > > > Another kind of vague one. We have found from our application
>>> logs
>>> at
>>> > > > site
>>> > > > > that some messages that we are sending appear to be sent OK on
>>> one
>>> > end
>>> > > > but
>>> > > > > are never received by the subscriber.
>>> > > > >
>>> > > > > This seems to coincide with topics where the traffic volume is
>>> low,
>>> > > does
>>> > > > > anyone have any pointers on where to look first?
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>>

Re: Shared File System Master Slave

[norinos]

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 master, even if the 
> client doesn't immediately reconnect. If the subscription is not durable, 
> then it will be recreated when the client reconnects to the new master, so 
> any messages that were unconsumed at the time the original master went
> down 
> and any messages sent before the client reconnects will be lost for that 
> subscriber.

I'm using durable subscription.
So, I understand that clients can receive the message without problems
when switching from master to slave.


Please tell me a little more.

ActiveMQ insert cache index into the reference store for performance at
checkpoint interval.

If master goes down, it seems that chache index can not insert.
So reference store is not up-to-date.

In this case, if I startup up ActiveMQ, Is the reference store updated at
the start-up phase?




--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: Message appears to be sent but not received

[Tim Bain]

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:

> 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 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 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 lots of data on other topics on the same connection.
>>
>>
>>
>>
>> On Sun, 8 Apr 2018 at 1:43 am, Tim Bain  wrote:
>>
>> > I'd suggest you use a JMX viewer such as JConsole, and navigate through
>> the
>> > org.apache.activemq MBeans to find the subscription in question. On the
>> > Attributes page under the subscription, you'll see counts for the number
>> of
>> > messages enqueued and dequeued.
>> >
>> > If those don't match, it means your messages are not getting delivered
>> to
>> > the subscriber. (Could they be expiring before they can be consumed?)
>> >
>> > If they match, but are lower than the number you sent to the topic while
>> > the consumer was subscribed, we'll have to dig deeper.
>> >
>> > Also, I understand from your response that these consumers have been
>> > subscribed and connected the entire time the messages were being sent.
>> Is
>> > that what you're saying?
>> >
>> > Tim
>> >
>> > On Fri, Apr 6, 2018 at 7:11 AM, Lionel van den Berg 
>> > wrote:
>> >
>> > > Non-durable an using the same connection as other topics that are
>> still
>> > > working. No filters.
>> > >
>> > >
>> > > On Fri, 6 Apr 2018 at 11:03 pm, Tim Bain 
>> wrote:
>> > >
>> > > > Are the topic subscriptions durable or non-durable? If the latter,
>> were
>> > > the
>> > > > clients disconnected at the time the messages in question were sent?
>> > > >
>> > > > Also, do the subscribers in question use any selectors?
>> > > >
>> > > > Tim
>> > > >
>> > > > On Fri, Apr 6, 2018, 12:26 AM Lionel van den Berg <
>> lion...@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > Another kind of vague one. We have found from our application logs
>> at
>> > > > site
>> > > > > that some messages that we are sending appear to be sent OK on one
>> > end
>> > > > but
>> > > > > are never received by the subscriber.
>> > > > >
>> > > > > This seems to coincide with topics where the traffic volume is
>> low,
>> > > does
>> > > > > anyone have any pointers on where to look first?
>> > > > >
>> > > >
>> > >
>> >
>>
>

Re: Message appears to be sent but not received

[Lionel van den Berg]

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 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 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 lots of data on other topics on the same connection.
>
>
>
>
> On Sun, 8 Apr 2018 at 1:43 am, Tim Bain  wrote:
>
> > I'd suggest you use a JMX viewer such as JConsole, and navigate through
> the
> > org.apache.activemq MBeans to find the subscription in question. On the
> > Attributes page under the subscription, you'll see counts for the number
> of
> > messages enqueued and dequeued.
> >
> > If those don't match, it means your messages are not getting delivered to
> > the subscriber. (Could they be expiring before they can be consumed?)
> >
> > If they match, but are lower than the number you sent to the topic while
> > the consumer was subscribed, we'll have to dig deeper.
> >
> > Also, I understand from your response that these consumers have been
> > subscribed and connected the entire time the messages were being sent. Is
> > that what you're saying?
> >
> > Tim
> >
> > On Fri, Apr 6, 2018 at 7:11 AM, Lionel van den Berg 
> > wrote:
> >
> > > Non-durable an using the same connection as other topics that are still
> > > working. No filters.
> > >
> > >
> > > On Fri, 6 Apr 2018 at 11:03 pm, Tim Bain 
> wrote:
> > >
> > > > Are the topic subscriptions durable or non-durable? If the latter,
> were
> > > the
> > > > clients disconnected at the time the messages in question were sent?
> > > >
> > > > Also, do the subscribers in question use any selectors?
> > > >
> > > > Tim
> > > >
> > > > On Fri, Apr 6, 2018, 12:26 AM Lionel van den Berg  >
> > > > wrote:
> > > >
> > > > > Another kind of vague one. We have found from our application logs
> at
> > > > site
> > > > > that some messages that we are sending appear to be sent OK on one
> > end
> > > > but
> > > > > are never received by the subscriber.
> > > > >
> > > > > This seems to coincide with topics where the traffic volume is low,
> > > does
> > > > > anyone have any pointers on where to look first?
> > > > >
> > > >
> > >
> >
>

Re: Message appears to be sent but not received

[Tim Bain]

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 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 lots of data on other topics on the same connection.




On Sun, 8 Apr 2018 at 1:43 am, Tim Bain  wrote:

> I'd suggest you use a JMX viewer such as JConsole, and navigate through
the
> org.apache.activemq MBeans to find the subscription in question. On the
> Attributes page under the subscription, you'll see counts for the number
of
> messages enqueued and dequeued.
>
> If those don't match, it means your messages are not getting delivered to
> the subscriber. (Could they be expiring before they can be consumed?)
>
> If they match, but are lower than the number you sent to the topic while
> the consumer was subscribed, we'll have to dig deeper.
>
> Also, I understand from your response that these consumers have been
> subscribed and connected the entire time the messages were being sent. Is
> that what you're saying?
>
> Tim
>
> On Fri, Apr 6, 2018 at 7:11 AM, Lionel van den Berg 
> wrote:
>
> > Non-durable an using the same connection as other topics that are still
> > working. No filters.
> >
> >
> > On Fri, 6 Apr 2018 at 11:03 pm, Tim Bain  wrote:
> >
> > > Are the topic subscriptions durable or non-durable? If the latter,
were
> > the
> > > clients disconnected at the time the messages in question were sent?
> > >
> > > Also, do the subscribers in question use any selectors?
> > >
> > > Tim
> > >
> > > On Fri, Apr 6, 2018, 12:26 AM Lionel van den Berg 
> > > wrote:
> > >
> > > > Another kind of vague one. We have found from our application logs
at
> > > site
> > > > that some messages that we are sending appear to be sent OK on one
> end
> > > but
> > > > are never received by the subscriber.
> > > >
> > > > This seems to coincide with topics where the traffic volume is low,
> > does
> > > > anyone have any pointers on where to look first?
> > > >
> > >
> >
>

Re: Message appears to be sent but not received

[Lionel van den Berg]

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 lots of data on other topics on the same connection.



On Sun, 8 Apr 2018 at 1:43 am, Tim Bain  wrote:

> I'd suggest you use a JMX viewer such as JConsole, and navigate through the
> org.apache.activemq MBeans to find the subscription in question. On the
> Attributes page under the subscription, you'll see counts for the number of
> messages enqueued and dequeued.
>
> If those don't match, it means your messages are not getting delivered to
> the subscriber. (Could they be expiring before they can be consumed?)
>
> If they match, but are lower than the number you sent to the topic while
> the consumer was subscribed, we'll have to dig deeper.
>
> Also, I understand from your response that these consumers have been
> subscribed and connected the entire time the messages were being sent. Is
> that what you're saying?
>
> Tim
>
> On Fri, Apr 6, 2018 at 7:11 AM, Lionel van den Berg 
> wrote:
>
> > Non-durable an using the same connection as other topics that are still
> > working. No filters.
> >
> >
> > On Fri, 6 Apr 2018 at 11:03 pm, Tim Bain  wrote:
> >
> > > Are the topic subscriptions durable or non-durable? If the latter, were
> > the
> > > clients disconnected at the time the messages in question were sent?
> > >
> > > Also, do the subscribers in question use any selectors?
> > >
> > > Tim
> > >
> > > On Fri, Apr 6, 2018, 12:26 AM Lionel van den Berg 
> > > wrote:
> > >
> > > > Another kind of vague one. We have found from our application logs at
> > > site
> > > > that some messages that we are sending appear to be sent OK on one
> end
> > > but
> > > > are never received by the subscriber.
> > > >
> > > > This seems to coincide with topics where the traffic volume is low,
> > does
> > > > anyone have any pointers on where to look first?
> > > >
> > >
> >
>

Re: Unexpected resend behavior when pulling messages using NMS .NET ReceiveNoWait

[asafm]

Problem solved, thanks to Tim's help: 
I replaced jms & nested prefixes by nms prefix, and removed one property
that was not supported, and consumer-side configuration now works.



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html