Subscriber losing messages (from topic)

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Subscriber losing messages (from topic)

kgardas
Hello,

I'm playing a bit with ActiveMQ 5.7.0 and found that under some
circumstances my subscriber looks like losing messages which are
delivered to him from the broker. Honestly speaking I don't know if to
blame subscriber or broker in this case but while looking into web
console of the broker, the broker claims the messages are delivered, but
I don't see them on subscriber. It took me some time to duplicate this
issue on as simple as possible example, but finally I've been able to a
bit hack activemq's own demo to duplicate it.

If you'd like to see the same effect as I see now, just go to
activemq/example/src and add:

try {
Thread.sleep(1);
}
catch (Exception ex) {
ex.printStackTrace();
}

into ConsumerTool.java's onMessage method. This will ensure that
onMessage on consumer will run a little bit slower than producer is able
to send messages and you will see the effect.

Once done, just run consumer with:

ant consumer -Dtopic=true -Dverbose=false -Dmax=1000000 -Dsubject=TRM

and producer with:

ant producer -Dtopic=true -Dverbose=false -Dmax=1000000 -Dsubject=TRM

if everything is working well, then both consumer and producer should
end once delivering 1000000 messages. The problem is that consumer does
not end due to losing some of the messages somewhere. If this does not
happen on your box, please increase number of milliseconds on
Thread.sleep to make onMessage even slower. I'm running this on Solaris
11/JDK 1.7 on Xeon E5 2.0 GHz here.

Now, I do have following questions:

- am I right assuming the example above should really deliver all the
messages to the consumer onMessage method?

- is this already known issue or shall I report it properly to
ActiveMQ's bug tracking system?

Just to make sure, I've also tried running consumer with ant consumer
-Dtopic=true -Dverbose=false -Dmax=1000000 -Dsubject=TRM
-Durl="tcp://localhost:61616?jms.prefetchPolicy.queuePrefetch=0" -- but
it neither helps. At least I've thought pre-fetching might cause this so
I tried...

BTW: I've seen the same issue but not on demo, but on our own
application also while running subscriber on top of 5.6.0 and 5.5.0
releases. I always used 5.7.0 release for broker and producer though.
I've not seen it on demo as I've not tested this with older releases but
I would guess the issue will be there too.


Thanks a lot for any idea about what's going wrong here.

Karel
Reply | Threaded
Open this post in threaded view
|

Subscriber losing messages (from topic)

kgardas

Hello,

I'm playing a bit with ActiveMQ 5.7.0 and found that under some
circumstances my subscriber looks like losing messages which are
delivered to him from the broker. Honestly speaking I don't know if to
blame subscriber or broker in this case but while looking into web
console of the broker, the broker claims the messages are delivered, but
I don't see them on subscriber. It took me some time to duplicate this
issue on as simple as possible example, but finally I've been able to a
bit hack activemq's own demo to duplicate it.

If you'd like to see the same effect as I see now, just go to
activemq/example/src and add:

try {
Thread.sleep(1);
}
catch (Exception ex) {
ex.printStackTrace();
}

into ConsumerTool.java's onMessage method. This will ensure that
onMessage on consumer will run a little bit slower than producer is able
to send messages and you will see the effect.

Once done, just run consumer with:

ant consumer -Dtopic=true -Dverbose=false -Dmax=1000000 -Dsubject=TRM

and producer with:

ant producer -Dtopic=true -Dverbose=false -Dmax=1000000 -Dsubject=TRM

if everything is working well, then both consumer and producer should
end once delivering 1000000 messages. The problem is that consumer does
not end due to losing some of the messages somewhere. If this does not
happen on your box, please increase number of milliseconds on
Thread.sleep to make onMessage even slower. I'm running this on Solaris
11/JDK 1.7 on Xeon E5 2.0 GHz here.

Now, I do have following questions:

- am I right assuming the example above should really deliver all the
messages to the consumer onMessage method?

- is this already known issue or shall I report it properly to
ActiveMQ's bug tracking system?

Just to make sure, I've also tried running consumer with ant consumer
-Dtopic=true -Dverbose=false -Dmax=1000000 -Dsubject=TRM
-Durl="tcp://localhost:61616?jms.prefetchPolicy.queuePrefetch=0" -- but
it neither helps. At least I've thought pre-fetching might cause this so
I tried...

BTW: I've seen the same issue but not on demo, but on our own
application also while running subscriber on top of 5.6.0 and 5.5.0
releases. I always used 5.7.0 release for broker and producer though.
I've not seen it on demo as I've not tested this with older releases but
I would guess the issue will be there too.


Thanks a lot for any idea about what's going wrong here.

Karel
PS: resending as my former subscription to the list looks like stuck in
the middle of the way. Sorry if it went through already.
Reply | Threaded
Open this post in threaded view
|

Re: Subscriber losing messages (from topic)

tabish121@gmail.com
On Thu, 2013-01-10 at 21:52 +0100, Karel Gardas wrote:

> Hello,
>
> I'm playing a bit with ActiveMQ 5.7.0 and found that under some
> circumstances my subscriber looks like losing messages which are
> delivered to him from the broker. Honestly speaking I don't know if to
> blame subscriber or broker in this case but while looking into web
> console of the broker, the broker claims the messages are delivered, but
> I don't see them on subscriber. It took me some time to duplicate this
> issue on as simple as possible example, but finally I've been able to a
> bit hack activemq's own demo to duplicate it.
>
> If you'd like to see the same effect as I see now, just go to
> activemq/example/src and add:
>

You should try to create a unit test to represent what's going on so
that we can take closer look.  Seems odd that the sleep would cause
something to get lost unless there's a TTL set on the messages.

> try {
> Thread.sleep(1);
> }
> catch (Exception ex) {
> ex.printStackTrace();
> }
>
> into ConsumerTool.java's onMessage method. This will ensure that
> onMessage on consumer will run a little bit slower than producer is able
> to send messages and you will see the effect.
>
> Once done, just run consumer with:
>
> ant consumer -Dtopic=true -Dverbose=false -Dmax=1000000 -Dsubject=TRM
>
> and producer with:
>
> ant producer -Dtopic=true -Dverbose=false -Dmax=1000000 -Dsubject=TRM
>
> if everything is working well, then both consumer and producer should
> end once delivering 1000000 messages. The problem is that consumer does
> not end due to losing some of the messages somewhere. If this does not
> happen on your box, please increase number of milliseconds on
> Thread.sleep to make onMessage even slower. I'm running this on Solaris
> 11/JDK 1.7 on Xeon E5 2.0 GHz here.
>
> Now, I do have following questions:
>
> - am I right assuming the example above should really deliver all the
> messages to the consumer onMessage method?
>
> - is this already known issue or shall I report it properly to
> ActiveMQ's bug tracking system?
>
> Just to make sure, I've also tried running consumer with ant consumer
> -Dtopic=true -Dverbose=false -Dmax=1000000 -Dsubject=TRM
> -Durl="tcp://localhost:61616?jms.prefetchPolicy.queuePrefetch=0" -- but
> it neither helps. At least I've thought pre-fetching might cause this so
> I tried...
>
> BTW: I've seen the same issue but not on demo, but on our own
> application also while running subscriber on top of 5.6.0 and 5.5.0
> releases. I always used 5.7.0 release for broker and producer though.
> I've not seen it on demo as I've not tested this with older releases but
> I would guess the issue will be there too.
>
>
> Thanks a lot for any idea about what's going wrong here.
>
> Karel
> PS: resending as my former subscription to the list looks like stuck in
> the middle of the way. Sorry if it went through already.

--
Tim Bish
Sr Software Engineer | RedHat Inc.
[hidden email] | www.fusesource.com | www.redhat.com
skype: tabish121 | twitter: @tabish121
blog: http://timbish.blogspot.com/

Reply | Threaded
Open this post in threaded view
|

Reply:Re: Subscriber losing messages (from topic)

SuoNayi-2
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Reply:Reply:Re: Subscriber losing messages (from topic)

SuoNayi-2
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Reply:Reply:Re: Subscriber losing messages (from topic)

kgardas

Hi,

thanks a lot for this fast help! Indeed, I've been using non-durable
subscriber so I'm glad this behavior is expected although for me it was
highly confusing.  Thanks for clarification. Now, when I've switched to
using durable subscriber I see all the messages are delivered to the
subscriber reliably, although way much slower than in case of
non-durable consumer. The ratio is like few minutes versus ~170 minutes.
Note that I'm using ActiveMQ db on Solaris' tmp file-system so
effectively it's whole located in RAM.

Now, I'm using stock ActiveMQ 5.7.0 release so I'm also using its own
default configuration.  Ideally for our application I would expect
slower consumer to block faster producer in case of reaching broker
internal memory limit. Is there some option in ActiveMQ configuration
file to switch this behavior on? I've seen this was discussed on
http://activemq.apache.org/slow-consumers.html as an option what to do
in case of slower consumer so I hope it is already implemented. Also I'd
like to avoid durable consumers as they seems to be much slower and more
importantly we don't need reconnect capability and delivering of
messages to reconnected consumer yet.

Thanks a lot!
Karel

On 01/11/13 03:03 AM, SuoNayi wrote:

> Sorry for my inaccurate post.
> The behavior that the broker discards messages for the slow non-durable subscription
> depends on the maximum pending messages of the subscription.
> There is a pending message limit strategy for the subscription called PendingMessageLimitStrategy.
> You may post your broker configuration file for more details.
>
>
>
>
> At 2013-01-11 09:40:38,SuoNayi<[hidden email]>  wrote:
>> Hi, I assume you're using non-durable subscription.
>> If so the eviction strategy will be involved when the memory consumption of the
>> broker exceeds the memory limit.In your case the producer is faster than the consumer.
>> This cause more and more messages are pending in memory in the broker
>> and eventually the broker has to use the eviction strategy to discard messages
>> for the slow non-durable subscription.The default strategy is oldestMessageEvictionStrategy
>> that will discard the oldest message in memory.You may take a look at
>> http://activemq.apache.org/slow-consumer-handling.html
>> In this case the behavior you observed is expected.
>>
>>
>>
>>
>>
>> At 2013-01-11 04:59:52,"Timothy Bish"<[hidden email]>  wrote:
>>> On Thu, 2013-01-10 at 21:52 +0100, Karel Gardas wrote:
>>>> Hello,
>>>>
>>>> I'm playing a bit with ActiveMQ 5.7.0 and found that under some
>>>> circumstances my subscriber looks like losing messages which are
>>>> delivered to him from the broker. Honestly speaking I don't know if to
>>>> blame subscriber or broker in this case but while looking into web
>>>> console of the broker, the broker claims the messages are delivered, but
>>>> I don't see them on subscriber. It took me some time to duplicate this
>>>> issue on as simple as possible example, but finally I've been able to a
>>>> bit hack activemq's own demo to duplicate it.
>>>>
>>>> If you'd like to see the same effect as I see now, just go to
>>>> activemq/example/src and add:
>>>>
>>>
>>> You should try to create a unit test to represent what's going on so
>>> that we can take closer look.  Seems odd that the sleep would cause
>>> something to get lost unless there's a TTL set on the messages.
>>>
>>>> try {
>>>> Thread.sleep(1);
>>>> }
>>>> catch (Exception ex) {
>>>> ex.printStackTrace();
>>>> }
>>>>
>>>> into ConsumerTool.java's onMessage method. This will ensure that
>>>> onMessage on consumer will run a little bit slower than producer is able
>>>> to send messages and you will see the effect.
>>>>
>>>> Once done, just run consumer with:
>>>>
>>>> ant consumer -Dtopic=true -Dverbose=false -Dmax=1000000 -Dsubject=TRM
>>>>
>>>> and producer with:
>>>>
>>>> ant producer -Dtopic=true -Dverbose=false -Dmax=1000000 -Dsubject=TRM
>>>>
>>>> if everything is working well, then both consumer and producer should
>>>> end once delivering 1000000 messages. The problem is that consumer does
>>>> not end due to losing some of the messages somewhere. If this does not
>>>> happen on your box, please increase number of milliseconds on
>>>> Thread.sleep to make onMessage even slower. I'm running this on Solaris
>>>> 11/JDK 1.7 on Xeon E5 2.0 GHz here.
>>>>
>>>> Now, I do have following questions:
>>>>
>>>> - am I right assuming the example above should really deliver all the
>>>> messages to the consumer onMessage method?
>>>>
>>>> - is this already known issue or shall I report it properly to
>>>> ActiveMQ's bug tracking system?
>>>>
>>>> Just to make sure, I've also tried running consumer with ant consumer
>>>> -Dtopic=true -Dverbose=false -Dmax=1000000 -Dsubject=TRM
>>>> -Durl="tcp://localhost:61616?jms.prefetchPolicy.queuePrefetch=0" -- but
>>>> it neither helps. At least I've thought pre-fetching might cause this so
>>>> I tried...
>>>>
>>>> BTW: I've seen the same issue but not on demo, but on our own
>>>> application also while running subscriber on top of 5.6.0 and 5.5.0
>>>> releases. I always used 5.7.0 release for broker and producer though.
>>>> I've not seen it on demo as I've not tested this with older releases but
>>>> I would guess the issue will be there too.
>>>>
>>>>
>>>> Thanks a lot for any idea about what's going wrong here.
>>>>
>>>> Karel
>>>> PS: resending as my former subscription to the list looks like stuck in
>>>> the middle of the way. Sorry if it went through already.
>>>
>>> --
>>> Tim Bish
>>> Sr Software Engineer | RedHat Inc.
>>> [hidden email] | www.fusesource.com | www.redhat.com
>>> skype: tabish121 | twitter: @tabish121
>>> blog: http://timbish.blogspot.com/
>>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Reply:Reply:Re: Subscriber losing messages (from topic)

kgardas

Oops, sorry for the question below, now I see you've already pointed me
into the right direction pointing to:
http://activemq.apache.org/slow-consumer-handling.html

I'm going to test it.

Thanks,
Karel

On 01/11/13 06:26 PM, Karel Gardas wrote:

>
> Hi,
>
> thanks a lot for this fast help! Indeed, I've been using non-durable
> subscriber so I'm glad this behavior is expected although for me it was
> highly confusing. Thanks for clarification. Now, when I've switched to
> using durable subscriber I see all the messages are delivered to the
> subscriber reliably, although way much slower than in case of
> non-durable consumer. The ratio is like few minutes versus ~170 minutes.
> Note that I'm using ActiveMQ db on Solaris' tmp file-system so
> effectively it's whole located in RAM.
>
> Now, I'm using stock ActiveMQ 5.7.0 release so I'm also using its own
> default configuration. Ideally for our application I would expect slower
> consumer to block faster producer in case of reaching broker internal
> memory limit. Is there some option in ActiveMQ configuration file to
> switch this behavior on? I've seen this was discussed on
> http://activemq.apache.org/slow-consumers.html as an option what to do
> in case of slower consumer so I hope it is already implemented. Also I'd
> like to avoid durable consumers as they seems to be much slower and more
> importantly we don't need reconnect capability and delivering of
> messages to reconnected consumer yet.
>
> Thanks a lot!
> Karel
>
> On 01/11/13 03:03 AM, SuoNayi wrote:
>> Sorry for my inaccurate post.
>> The behavior that the broker discards messages for the slow
>> non-durable subscription
>> depends on the maximum pending messages of the subscription.
>> There is a pending message limit strategy for the subscription called
>> PendingMessageLimitStrategy.
>> You may post your broker configuration file for more details.
>>
>>
>>
>>
>> At 2013-01-11 09:40:38,SuoNayi<[hidden email]> wrote:
>>> Hi, I assume you're using non-durable subscription.
>>> If so the eviction strategy will be involved when the memory
>>> consumption of the
>>> broker exceeds the memory limit.In your case the producer is faster
>>> than the consumer.
>>> This cause more and more messages are pending in memory in the broker
>>> and eventually the broker has to use the eviction strategy to discard
>>> messages
>>> for the slow non-durable subscription.The default strategy is
>>> oldestMessageEvictionStrategy
>>> that will discard the oldest message in memory.You may take a look at
>>> http://activemq.apache.org/slow-consumer-handling.html
>>> In this case the behavior you observed is expected.
>>>
>>>
>>>
>>>
>>>
>>> At 2013-01-11 04:59:52,"Timothy Bish"<[hidden email]> wrote:
>>>> On Thu, 2013-01-10 at 21:52 +0100, Karel Gardas wrote:
>>>>> Hello,
>>>>>
>>>>> I'm playing a bit with ActiveMQ 5.7.0 and found that under some
>>>>> circumstances my subscriber looks like losing messages which are
>>>>> delivered to him from the broker. Honestly speaking I don't know if to
>>>>> blame subscriber or broker in this case but while looking into web
>>>>> console of the broker, the broker claims the messages are
>>>>> delivered, but
>>>>> I don't see them on subscriber. It took me some time to duplicate this
>>>>> issue on as simple as possible example, but finally I've been able
>>>>> to a
>>>>> bit hack activemq's own demo to duplicate it.
>>>>>
>>>>> If you'd like to see the same effect as I see now, just go to
>>>>> activemq/example/src and add:
>>>>>
>>>>
>>>> You should try to create a unit test to represent what's going on so
>>>> that we can take closer look. Seems odd that the sleep would cause
>>>> something to get lost unless there's a TTL set on the messages.
>>>>
>>>>> try {
>>>>> Thread.sleep(1);
>>>>> }
>>>>> catch (Exception ex) {
>>>>> ex.printStackTrace();
>>>>> }
>>>>>
>>>>> into ConsumerTool.java's onMessage method. This will ensure that
>>>>> onMessage on consumer will run a little bit slower than producer is
>>>>> able
>>>>> to send messages and you will see the effect.
>>>>>
>>>>> Once done, just run consumer with:
>>>>>
>>>>> ant consumer -Dtopic=true -Dverbose=false -Dmax=1000000 -Dsubject=TRM
>>>>>
>>>>> and producer with:
>>>>>
>>>>> ant producer -Dtopic=true -Dverbose=false -Dmax=1000000 -Dsubject=TRM
>>>>>
>>>>> if everything is working well, then both consumer and producer should
>>>>> end once delivering 1000000 messages. The problem is that consumer
>>>>> does
>>>>> not end due to losing some of the messages somewhere. If this does not
>>>>> happen on your box, please increase number of milliseconds on
>>>>> Thread.sleep to make onMessage even slower. I'm running this on
>>>>> Solaris
>>>>> 11/JDK 1.7 on Xeon E5 2.0 GHz here.
>>>>>
>>>>> Now, I do have following questions:
>>>>>
>>>>> - am I right assuming the example above should really deliver all the
>>>>> messages to the consumer onMessage method?
>>>>>
>>>>> - is this already known issue or shall I report it properly to
>>>>> ActiveMQ's bug tracking system?
>>>>>
>>>>> Just to make sure, I've also tried running consumer with ant consumer
>>>>> -Dtopic=true -Dverbose=false -Dmax=1000000 -Dsubject=TRM
>>>>> -Durl="tcp://localhost:61616?jms.prefetchPolicy.queuePrefetch=0" --
>>>>> but
>>>>> it neither helps. At least I've thought pre-fetching might cause
>>>>> this so
>>>>> I tried...
>>>>>
>>>>> BTW: I've seen the same issue but not on demo, but on our own
>>>>> application also while running subscriber on top of 5.6.0 and 5.5.0
>>>>> releases. I always used 5.7.0 release for broker and producer though.
>>>>> I've not seen it on demo as I've not tested this with older
>>>>> releases but
>>>>> I would guess the issue will be there too.
>>>>>
>>>>>
>>>>> Thanks a lot for any idea about what's going wrong here.
>>>>>
>>>>> Karel
>>>>> PS: resending as my former subscription to the list looks like
>>>>> stuck in
>>>>> the middle of the way. Sorry if it went through already.
>>>>
>>>> --
>>>> Tim Bish
>>>> Sr Software Engineer | RedHat Inc.
>>>> [hidden email] | www.fusesource.com | www.redhat.com
>>>> skype: tabish121 | twitter: @tabish121
>>>> blog: http://timbish.blogspot.com/
>>>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Reply:Reply:Re: Subscriber losing messages (from topic)

tabish121@gmail.com
On Fri, 2013-01-11 at 18:29 +0100, Karel Gardas wrote:
> Oops, sorry for the question below, now I see you've already pointed me
> into the right direction pointing to:
> http://activemq.apache.org/slow-consumer-handling.html
>
> I'm going to test it.

You may also want to have a look at this Blog on the ActiveMQ
MemeroyUsage:
http://www.christianposta.com/blog/?p=273 

>
> Thanks,
> Karel
>
> On 01/11/13 06:26 PM, Karel Gardas wrote:
> >
> > Hi,
> >
> > thanks a lot for this fast help! Indeed, I've been using non-durable
> > subscriber so I'm glad this behavior is expected although for me it was
> > highly confusing. Thanks for clarification. Now, when I've switched to
> > using durable subscriber I see all the messages are delivered to the
> > subscriber reliably, although way much slower than in case of
> > non-durable consumer. The ratio is like few minutes versus ~170 minutes.
> > Note that I'm using ActiveMQ db on Solaris' tmp file-system so
> > effectively it's whole located in RAM.
> >
> > Now, I'm using stock ActiveMQ 5.7.0 release so I'm also using its own
> > default configuration. Ideally for our application I would expect slower
> > consumer to block faster producer in case of reaching broker internal
> > memory limit. Is there some option in ActiveMQ configuration file to
> > switch this behavior on? I've seen this was discussed on
> > http://activemq.apache.org/slow-consumers.html as an option what to do
> > in case of slower consumer so I hope it is already implemented. Also I'd
> > like to avoid durable consumers as they seems to be much slower and more
> > importantly we don't need reconnect capability and delivering of
> > messages to reconnected consumer yet.
> >
> > Thanks a lot!
> > Karel
> >
> > On 01/11/13 03:03 AM, SuoNayi wrote:
> >> Sorry for my inaccurate post.
> >> The behavior that the broker discards messages for the slow
> >> non-durable subscription
> >> depends on the maximum pending messages of the subscription.
> >> There is a pending message limit strategy for the subscription called
> >> PendingMessageLimitStrategy.
> >> You may post your broker configuration file for more details.
> >>
> >>
> >>
> >>
> >> At 2013-01-11 09:40:38,SuoNayi<[hidden email]> wrote:
> >>> Hi, I assume you're using non-durable subscription.
> >>> If so the eviction strategy will be involved when the memory
> >>> consumption of the
> >>> broker exceeds the memory limit.In your case the producer is faster
> >>> than the consumer.
> >>> This cause more and more messages are pending in memory in the broker
> >>> and eventually the broker has to use the eviction strategy to discard
> >>> messages
> >>> for the slow non-durable subscription.The default strategy is
> >>> oldestMessageEvictionStrategy
> >>> that will discard the oldest message in memory.You may take a look at
> >>> http://activemq.apache.org/slow-consumer-handling.html
> >>> In this case the behavior you observed is expected.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> At 2013-01-11 04:59:52,"Timothy Bish"<[hidden email]> wrote:
> >>>> On Thu, 2013-01-10 at 21:52 +0100, Karel Gardas wrote:
> >>>>> Hello,
> >>>>>
> >>>>> I'm playing a bit with ActiveMQ 5.7.0 and found that under some
> >>>>> circumstances my subscriber looks like losing messages which are
> >>>>> delivered to him from the broker. Honestly speaking I don't know if to
> >>>>> blame subscriber or broker in this case but while looking into web
> >>>>> console of the broker, the broker claims the messages are
> >>>>> delivered, but
> >>>>> I don't see them on subscriber. It took me some time to duplicate this
> >>>>> issue on as simple as possible example, but finally I've been able
> >>>>> to a
> >>>>> bit hack activemq's own demo to duplicate it.
> >>>>>
> >>>>> If you'd like to see the same effect as I see now, just go to
> >>>>> activemq/example/src and add:
> >>>>>
> >>>>
> >>>> You should try to create a unit test to represent what's going on so
> >>>> that we can take closer look. Seems odd that the sleep would cause
> >>>> something to get lost unless there's a TTL set on the messages.
> >>>>
> >>>>> try {
> >>>>> Thread.sleep(1);
> >>>>> }
> >>>>> catch (Exception ex) {
> >>>>> ex.printStackTrace();
> >>>>> }
> >>>>>
> >>>>> into ConsumerTool.java's onMessage method. This will ensure that
> >>>>> onMessage on consumer will run a little bit slower than producer is
> >>>>> able
> >>>>> to send messages and you will see the effect.
> >>>>>
> >>>>> Once done, just run consumer with:
> >>>>>
> >>>>> ant consumer -Dtopic=true -Dverbose=false -Dmax=1000000 -Dsubject=TRM
> >>>>>
> >>>>> and producer with:
> >>>>>
> >>>>> ant producer -Dtopic=true -Dverbose=false -Dmax=1000000 -Dsubject=TRM
> >>>>>
> >>>>> if everything is working well, then both consumer and producer should
> >>>>> end once delivering 1000000 messages. The problem is that consumer
> >>>>> does
> >>>>> not end due to losing some of the messages somewhere. If this does not
> >>>>> happen on your box, please increase number of milliseconds on
> >>>>> Thread.sleep to make onMessage even slower. I'm running this on
> >>>>> Solaris
> >>>>> 11/JDK 1.7 on Xeon E5 2.0 GHz here.
> >>>>>
> >>>>> Now, I do have following questions:
> >>>>>
> >>>>> - am I right assuming the example above should really deliver all the
> >>>>> messages to the consumer onMessage method?
> >>>>>
> >>>>> - is this already known issue or shall I report it properly to
> >>>>> ActiveMQ's bug tracking system?
> >>>>>
> >>>>> Just to make sure, I've also tried running consumer with ant consumer
> >>>>> -Dtopic=true -Dverbose=false -Dmax=1000000 -Dsubject=TRM
> >>>>> -Durl="tcp://localhost:61616?jms.prefetchPolicy.queuePrefetch=0" --
> >>>>> but
> >>>>> it neither helps. At least I've thought pre-fetching might cause
> >>>>> this so
> >>>>> I tried...
> >>>>>
> >>>>> BTW: I've seen the same issue but not on demo, but on our own
> >>>>> application also while running subscriber on top of 5.6.0 and 5.5.0
> >>>>> releases. I always used 5.7.0 release for broker and producer though.
> >>>>> I've not seen it on demo as I've not tested this with older
> >>>>> releases but
> >>>>> I would guess the issue will be there too.
> >>>>>
> >>>>>
> >>>>> Thanks a lot for any idea about what's going wrong here.
> >>>>>
> >>>>> Karel
> >>>>> PS: resending as my former subscription to the list looks like
> >>>>> stuck in
> >>>>> the middle of the way. Sorry if it went through already.
> >>>>
> >>>> --
> >>>> Tim Bish
> >>>> Sr Software Engineer | RedHat Inc.
> >>>> [hidden email] | www.fusesource.com | www.redhat.com
> >>>> skype: tabish121 | twitter: @tabish121
> >>>> blog: http://timbish.blogspot.com/
> >>>>
> >>
> >
> >
>

--
Tim Bish
Sr Software Engineer | RedHat Inc.
[hidden email] | www.fusesource.com | www.redhat.com
skype: tabish121 | twitter: @tabish121
blog: http://timbish.blogspot.com/