You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Bryan Murphy <bm...@gmail.com> on 2008/08/28 21:36:32 UTC
ActiveMQ + NMS = Stalled Message Queues
Hey Guys,
I'm new to ActiveMQ and am running into a problem that has me
stumped. We're using NMS to communicate with an ActiveMQ message
broker. After a random period of time our consumers stop receiving
messages. Our producers do not seem to have any difficulty delivering
messages.
You can view the code we use to send our messages here:
http://pastebin.com/f7e1a6dd3
You can view the code we use to consume our messages here:
http://pastebin.com/f2d146b3b
We process the messages transactionally. I've put an obscene amount of
tracing into our code, and as far as I can tell the consumers simply stop
receiving messages. I can usually rectify the problem by restarting the
stalled service, however, on occasion I actually have to restart the
ActiveMQ message broker itself to get messages flowing again!
Could somebody help me determine what I am doing wrong, or at least point me
in the direction so I determine what the queues are blocking on?
Additional Info:
* ActiveMQ 5.1.0 (100% default configuration, download, untar, and run)
* Java 1.6.0_06-b02
* Ubuntu 8.04.1 (100% up to date) & Windows Server 2003
* Mono 2.0p1 & Microsoft .NET Framework 3.5
* Apache.NMS and Apache.NMS.ActiveMQ built from trunk as of yesterday
* tcp://ADDRESS:61616 connect to broker (over public internet), no other
options
Thanks,
Bryan
Re: ActiveMQ + NMS = Stalled Message Queues
Posted by Mario Siegenthaler <ms...@inventsoft.ch>.
I've seen the same behaviour today with an ActiveMQ 5.1.0 (JDBC-only
storage) and Java consumers (transactional).
The cause in my case was the AMQ-1838 bug which resulted in a huge
number of messages being paged in and the fetcher from the queue had
it's AtomicLong-lastMessageId set to a number slightly bigger than the
max. id of messages for that queue in the database. I'm not sure why
that happened, I suspect it just read over the messages and after
running out of memory it just started to discard them in the page-in
(not in the database, a broker restart did always fix the problem).
So I just applied the patch attached to AMQ-1838 and I could receive 1
Mio. messages without any trouble.
The fastest way to see whether you run into the same issue is to look
at the memory consumed by ActiveMQ during the message consumption.
Without the bug (aka with the patch) it stays flat, with the bug it
would grow fast to the configured memory limit.
--Mario
On Fri, Aug 29, 2008 at 5:01 PM, Bryan Murphy <bm...@gmail.com> wrote:
> More information...
> There were ~ 4,000 messages still pending in the queue. I took a closer
> look at the two active consumers under jconsole, the consumer that was
> running had approximately 800 messages in it's
> MessageCountAwaitingAcknowledge, the consumer that was idle had 0.
>
> I put a few new messages into the message queue, and this caused the idle
> process to unblock and start processing messages. Whatever this did, it
> unstuck the idle process and I now have significantly less than 4,000
> messages and it's continuing to tick downwards.
>
> It's pretty clear that ActiveMQ decided to stop sending messages to my
> consumer.
Re: ActiveMQ + NMS = Stalled Message Queues
Posted by Bryan Murphy <bm...@gmail.com>.
Ok, I'll give that a shot. I just set my prefetch size to 1 in production.
I'm going to monitor that for a bit and see what happens, but it already
stopped once. I had not restarted the ActiveMQ process, so I restarted
everything.
Also, I'm planning to downgrade to the 4.x builds of ActiveMQ to see if that
makes a difference.
Bryan
On Fri, Aug 29, 2008 at 11:47 AM, Vadim Chekan <ko...@gmail.com>wrote:
> Waiting in Reader from binary stream: that's expected. Another thread
> in dispatcher is normal too.
> I think you need to turn on debugging on the client side. See my
> article on how to do it:
>
> http://vchekan.blogspot.com/2008/08/tracing-in-nms-it-easy-to-turn-protocol.html
>
> Vadim.
>
>
> On Fri, Aug 29, 2008 at 8:01 AM, Bryan Murphy <bm...@gmail.com>
> wrote:
> > More information...
> > There were ~ 4,000 messages still pending in the queue. I took a closer
> > look at the two active consumers under jconsole, the consumer that was
> > running had approximately 800 messages in it's
> > MessageCountAwaitingAcknowledge, the consumer that was idle had 0.
> >
> > I put a few new messages into the message queue, and this caused the idle
> > process to unblock and start processing messages. Whatever this did, it
> > unstuck the idle process and I now have significantly less than 4,000
> > messages and it's continuing to tick downwards.
> >
> > It's pretty clear that ActiveMQ decided to stop sending messages to my
> > consumer.
> >
> > Bryan
> >
> > On Fri, Aug 29, 2008 at 9:40 AM, Bryan Murphy <bm...@gmail.com>
> wrote:
> >
> >> I changed my consumers to use client-acknowledge and immediately
> >> acknowledge the message upon receipt. My handler does the following:
> >>
> >> void Handle(IMessage message)
> >> {
> >> log message
> >> acknowledge message
> >> Thread.Sleep(random amount of time);
> >> }
> >>
> >> I bound the handler to consumer.Listen. I started two processes last
> >> night, one that sleeps randomly from 0 to 1,000ms, and another that
> sleeps
> >> randomly from 0 to 30,000ms.
> >>
> >> This morning, when I got in, the process that sleeps for up to 1000ms is
> >> idle, and the process that sleeps for up to 30,000ms is still handling
> >> messages.
> >>
> >> I attached the debugger to the idle process and it has three active
> >> threads. One is in my code where I sit in a while(true) {
> Thread.Sleep(); }
> >> loop to prevent the application from exiting, and the other two are
> ActiveMQ
> >> threads.
> >>
> >> Thead appears to be blocked trying to read binary data from the tcp
> stream
> >> :
> >> * OpenWireBinaryReader.cs line 132
> >> * OpenWireFormat.cs line 165
> >> * TcpTransport.cs line 266
> >>
> >> Thread two is blocked waiting for an AutoResetEvent:
> >> * DispatchingThread.cs line 125
> >>
> >> I opened up jconsole and took a look at the ActiveMQ process but I'm no
> >> expert with that and couldn't find anything obviously wrong. I'm at a
> loss
> >> what to do next.
> >>
> >> Thanks,
> >> Bryan
> >>
> >> On Thu, Aug 28, 2008 at 9:01 PM, Bryan Murphy <bmurphy1976@gmail.com
> >wrote:
> >>
> >>> I read more about calling acknowledge, and as far as I can tell,
> because I
> >>> was using transactional acknowledgement as well as session commit and
> >>> rollback, the call to acknowledge would have been a no-op.
> >>> Now, some of my transactions are in fact very long transactions. We
> have
> >>> two sets of services, one that sits in our data center near our
> database,
> >>> and another one that sits out on Amazon's EC2 cloud processing audio
> and
> >>> video files and syncing them up to S3. The service by our database
> handles
> >>> messages very quickly and never takes longer than a second (in theory),
> >>> however, it often sends out new messages as part of the transaction
> (which
> >>> I'll get to below).
> >>>
> >>> The services out on EC2 can take minutes to execute and hold the
> >>> transaction open the whole time. It may very well be the case that
> ActiveMQ
> >>> thinks my consumers are slow and is throttling them.
> >>>
> >>> The database handlers fail more often than the EC2 handlers. I found
> this
> >>> odd at first, until I added some performance metrics to our tracing.
> It
> >>> turns out (on my local machine at least) that establishing a connection
> can
> >>> take upwards of 4.5 seconds. We establish a new connection and a new
> >>> session every single time we send a message out. Most of the handlers
> on
> >>> our database side send out at least one message, so the transactions
> are
> >>> held open for at least that long.
> >>>
> >>> So, it's obvious to me that there's no connection pooling going on and
> >>> reading the FAQ confirms this. Assuming there was connection pooling
> was
> >>> clearly a bad assumption on my part. We don't use spring internally,
> so we
> >>> have no pre-built components available to handle connection pooling.
> For
> >>> now, I'm going to deal with it by simply moving away from transactional
> >>> message processing, and immediately acknowledging every message when it
> is
> >>> received. I'll deal with the consequences of failing message handlers
> >>> later.
> >>>
> >>> I was also consuming messages in a very different fashion last time I
> used
> >>> a non-transactional method, so perhaps this change in combination with
> that
> >>> previous change will get my system into working order. Once again,
> I'll
> >>> post back here with the results of these changes.
> >>>
> >>> If you notice any flaw in my reasoning, please do tell me. :)
> >>>
> >>> Thanks,
> >>> Bryan
> >>>
> >>>
> >
>
>
>
> --
> From RFC 2631: In ASN.1, EXPLICIT tagging is implicit unless IMPLICIT
> is explicitly specified
>
Re: ActiveMQ + NMS = Stalled Message Queues
Posted by Vadim Chekan <ko...@gmail.com>.
Waiting in Reader from binary stream: that's expected. Another thread
in dispatcher is normal too.
I think you need to turn on debugging on the client side. See my
article on how to do it:
http://vchekan.blogspot.com/2008/08/tracing-in-nms-it-easy-to-turn-protocol.html
Vadim.
On Fri, Aug 29, 2008 at 8:01 AM, Bryan Murphy <bm...@gmail.com> wrote:
> More information...
> There were ~ 4,000 messages still pending in the queue. I took a closer
> look at the two active consumers under jconsole, the consumer that was
> running had approximately 800 messages in it's
> MessageCountAwaitingAcknowledge, the consumer that was idle had 0.
>
> I put a few new messages into the message queue, and this caused the idle
> process to unblock and start processing messages. Whatever this did, it
> unstuck the idle process and I now have significantly less than 4,000
> messages and it's continuing to tick downwards.
>
> It's pretty clear that ActiveMQ decided to stop sending messages to my
> consumer.
>
> Bryan
>
> On Fri, Aug 29, 2008 at 9:40 AM, Bryan Murphy <bm...@gmail.com> wrote:
>
>> I changed my consumers to use client-acknowledge and immediately
>> acknowledge the message upon receipt. My handler does the following:
>>
>> void Handle(IMessage message)
>> {
>> log message
>> acknowledge message
>> Thread.Sleep(random amount of time);
>> }
>>
>> I bound the handler to consumer.Listen. I started two processes last
>> night, one that sleeps randomly from 0 to 1,000ms, and another that sleeps
>> randomly from 0 to 30,000ms.
>>
>> This morning, when I got in, the process that sleeps for up to 1000ms is
>> idle, and the process that sleeps for up to 30,000ms is still handling
>> messages.
>>
>> I attached the debugger to the idle process and it has three active
>> threads. One is in my code where I sit in a while(true) { Thread.Sleep(); }
>> loop to prevent the application from exiting, and the other two are ActiveMQ
>> threads.
>>
>> Thead appears to be blocked trying to read binary data from the tcp stream
>> :
>> * OpenWireBinaryReader.cs line 132
>> * OpenWireFormat.cs line 165
>> * TcpTransport.cs line 266
>>
>> Thread two is blocked waiting for an AutoResetEvent:
>> * DispatchingThread.cs line 125
>>
>> I opened up jconsole and took a look at the ActiveMQ process but I'm no
>> expert with that and couldn't find anything obviously wrong. I'm at a loss
>> what to do next.
>>
>> Thanks,
>> Bryan
>>
>> On Thu, Aug 28, 2008 at 9:01 PM, Bryan Murphy <bm...@gmail.com>wrote:
>>
>>> I read more about calling acknowledge, and as far as I can tell, because I
>>> was using transactional acknowledgement as well as session commit and
>>> rollback, the call to acknowledge would have been a no-op.
>>> Now, some of my transactions are in fact very long transactions. We have
>>> two sets of services, one that sits in our data center near our database,
>>> and another one that sits out on Amazon's EC2 cloud processing audio and
>>> video files and syncing them up to S3. The service by our database handles
>>> messages very quickly and never takes longer than a second (in theory),
>>> however, it often sends out new messages as part of the transaction (which
>>> I'll get to below).
>>>
>>> The services out on EC2 can take minutes to execute and hold the
>>> transaction open the whole time. It may very well be the case that ActiveMQ
>>> thinks my consumers are slow and is throttling them.
>>>
>>> The database handlers fail more often than the EC2 handlers. I found this
>>> odd at first, until I added some performance metrics to our tracing. It
>>> turns out (on my local machine at least) that establishing a connection can
>>> take upwards of 4.5 seconds. We establish a new connection and a new
>>> session every single time we send a message out. Most of the handlers on
>>> our database side send out at least one message, so the transactions are
>>> held open for at least that long.
>>>
>>> So, it's obvious to me that there's no connection pooling going on and
>>> reading the FAQ confirms this. Assuming there was connection pooling was
>>> clearly a bad assumption on my part. We don't use spring internally, so we
>>> have no pre-built components available to handle connection pooling. For
>>> now, I'm going to deal with it by simply moving away from transactional
>>> message processing, and immediately acknowledging every message when it is
>>> received. I'll deal with the consequences of failing message handlers
>>> later.
>>>
>>> I was also consuming messages in a very different fashion last time I used
>>> a non-transactional method, so perhaps this change in combination with that
>>> previous change will get my system into working order. Once again, I'll
>>> post back here with the results of these changes.
>>>
>>> If you notice any flaw in my reasoning, please do tell me. :)
>>>
>>> Thanks,
>>> Bryan
>>>
>>>
>
--
>From RFC 2631: In ASN.1, EXPLICIT tagging is implicit unless IMPLICIT
is explicitly specified
Re: ActiveMQ + NMS = Stalled Message Queues
Posted by Bryan Murphy <bm...@gmail.com>.
More information...
There were ~ 4,000 messages still pending in the queue. I took a closer
look at the two active consumers under jconsole, the consumer that was
running had approximately 800 messages in it's
MessageCountAwaitingAcknowledge, the consumer that was idle had 0.
I put a few new messages into the message queue, and this caused the idle
process to unblock and start processing messages. Whatever this did, it
unstuck the idle process and I now have significantly less than 4,000
messages and it's continuing to tick downwards.
It's pretty clear that ActiveMQ decided to stop sending messages to my
consumer.
Bryan
On Fri, Aug 29, 2008 at 9:40 AM, Bryan Murphy <bm...@gmail.com> wrote:
> I changed my consumers to use client-acknowledge and immediately
> acknowledge the message upon receipt. My handler does the following:
>
> void Handle(IMessage message)
> {
> log message
> acknowledge message
> Thread.Sleep(random amount of time);
> }
>
> I bound the handler to consumer.Listen. I started two processes last
> night, one that sleeps randomly from 0 to 1,000ms, and another that sleeps
> randomly from 0 to 30,000ms.
>
> This morning, when I got in, the process that sleeps for up to 1000ms is
> idle, and the process that sleeps for up to 30,000ms is still handling
> messages.
>
> I attached the debugger to the idle process and it has three active
> threads. One is in my code where I sit in a while(true) { Thread.Sleep(); }
> loop to prevent the application from exiting, and the other two are ActiveMQ
> threads.
>
> Thead appears to be blocked trying to read binary data from the tcp stream
> :
> * OpenWireBinaryReader.cs line 132
> * OpenWireFormat.cs line 165
> * TcpTransport.cs line 266
>
> Thread two is blocked waiting for an AutoResetEvent:
> * DispatchingThread.cs line 125
>
> I opened up jconsole and took a look at the ActiveMQ process but I'm no
> expert with that and couldn't find anything obviously wrong. I'm at a loss
> what to do next.
>
> Thanks,
> Bryan
>
> On Thu, Aug 28, 2008 at 9:01 PM, Bryan Murphy <bm...@gmail.com>wrote:
>
>> I read more about calling acknowledge, and as far as I can tell, because I
>> was using transactional acknowledgement as well as session commit and
>> rollback, the call to acknowledge would have been a no-op.
>> Now, some of my transactions are in fact very long transactions. We have
>> two sets of services, one that sits in our data center near our database,
>> and another one that sits out on Amazon's EC2 cloud processing audio and
>> video files and syncing them up to S3. The service by our database handles
>> messages very quickly and never takes longer than a second (in theory),
>> however, it often sends out new messages as part of the transaction (which
>> I'll get to below).
>>
>> The services out on EC2 can take minutes to execute and hold the
>> transaction open the whole time. It may very well be the case that ActiveMQ
>> thinks my consumers are slow and is throttling them.
>>
>> The database handlers fail more often than the EC2 handlers. I found this
>> odd at first, until I added some performance metrics to our tracing. It
>> turns out (on my local machine at least) that establishing a connection can
>> take upwards of 4.5 seconds. We establish a new connection and a new
>> session every single time we send a message out. Most of the handlers on
>> our database side send out at least one message, so the transactions are
>> held open for at least that long.
>>
>> So, it's obvious to me that there's no connection pooling going on and
>> reading the FAQ confirms this. Assuming there was connection pooling was
>> clearly a bad assumption on my part. We don't use spring internally, so we
>> have no pre-built components available to handle connection pooling. For
>> now, I'm going to deal with it by simply moving away from transactional
>> message processing, and immediately acknowledging every message when it is
>> received. I'll deal with the consequences of failing message handlers
>> later.
>>
>> I was also consuming messages in a very different fashion last time I used
>> a non-transactional method, so perhaps this change in combination with that
>> previous change will get my system into working order. Once again, I'll
>> post back here with the results of these changes.
>>
>> If you notice any flaw in my reasoning, please do tell me. :)
>>
>> Thanks,
>> Bryan
>>
>>
Re: ActiveMQ + NMS = Stalled Message Queues
Posted by Bryan Murphy <bm...@gmail.com>.
I changed my consumers to use client-acknowledge and immediately acknowledge
the message upon receipt. My handler does the following:
void Handle(IMessage message)
{
log message
acknowledge message
Thread.Sleep(random amount of time);
}
I bound the handler to consumer.Listen. I started two processes last night,
one that sleeps randomly from 0 to 1,000ms, and another that sleeps randomly
from 0 to 30,000ms.
This morning, when I got in, the process that sleeps for up to 1000ms is
idle, and the process that sleeps for up to 30,000ms is still handling
messages.
I attached the debugger to the idle process and it has three active
threads. One is in my code where I sit in a while(true) { Thread.Sleep(); }
loop to prevent the application from exiting, and the other two are ActiveMQ
threads.
Thead appears to be blocked trying to read binary data from the tcp stream :
* OpenWireBinaryReader.cs line 132
* OpenWireFormat.cs line 165
* TcpTransport.cs line 266
Thread two is blocked waiting for an AutoResetEvent:
* DispatchingThread.cs line 125
I opened up jconsole and took a look at the ActiveMQ process but I'm no
expert with that and couldn't find anything obviously wrong. I'm at a loss
what to do next.
Thanks,
Bryan
On Thu, Aug 28, 2008 at 9:01 PM, Bryan Murphy <bm...@gmail.com> wrote:
> I read more about calling acknowledge, and as far as I can tell, because I
> was using transactional acknowledgement as well as session commit and
> rollback, the call to acknowledge would have been a no-op.
> Now, some of my transactions are in fact very long transactions. We have
> two sets of services, one that sits in our data center near our database,
> and another one that sits out on Amazon's EC2 cloud processing audio and
> video files and syncing them up to S3. The service by our database handles
> messages very quickly and never takes longer than a second (in theory),
> however, it often sends out new messages as part of the transaction (which
> I'll get to below).
>
> The services out on EC2 can take minutes to execute and hold the
> transaction open the whole time. It may very well be the case that ActiveMQ
> thinks my consumers are slow and is throttling them.
>
> The database handlers fail more often than the EC2 handlers. I found this
> odd at first, until I added some performance metrics to our tracing. It
> turns out (on my local machine at least) that establishing a connection can
> take upwards of 4.5 seconds. We establish a new connection and a new
> session every single time we send a message out. Most of the handlers on
> our database side send out at least one message, so the transactions are
> held open for at least that long.
>
> So, it's obvious to me that there's no connection pooling going on and
> reading the FAQ confirms this. Assuming there was connection pooling was
> clearly a bad assumption on my part. We don't use spring internally, so we
> have no pre-built components available to handle connection pooling. For
> now, I'm going to deal with it by simply moving away from transactional
> message processing, and immediately acknowledging every message when it is
> received. I'll deal with the consequences of failing message handlers
> later.
>
> I was also consuming messages in a very different fashion last time I used
> a non-transactional method, so perhaps this change in combination with that
> previous change will get my system into working order. Once again, I'll
> post back here with the results of these changes.
>
> If you notice any flaw in my reasoning, please do tell me. :)
>
> Thanks,
> Bryan
>
>
Re: ActiveMQ + NMS = Stalled Message Queues
Posted by Bryan Murphy <bm...@gmail.com>.
I read more about calling acknowledge, and as far as I can tell, because I
was using transactional acknowledgement as well as session commit and
rollback, the call to acknowledge would have been a no-op.
Now, some of my transactions are in fact very long transactions. We have
two sets of services, one that sits in our data center near our database,
and another one that sits out on Amazon's EC2 cloud processing audio and
video files and syncing them up to S3. The service by our database handles
messages very quickly and never takes longer than a second (in theory),
however, it often sends out new messages as part of the transaction (which
I'll get to below).
The services out on EC2 can take minutes to execute and hold the transaction
open the whole time. It may very well be the case that ActiveMQ thinks my
consumers are slow and is throttling them.
The database handlers fail more often than the EC2 handlers. I found this
odd at first, until I added some performance metrics to our tracing. It
turns out (on my local machine at least) that establishing a connection can
take upwards of 4.5 seconds. We establish a new connection and a new
session every single time we send a message out. Most of the handlers on
our database side send out at least one message, so the transactions are
held open for at least that long.
So, it's obvious to me that there's no connection pooling going on and
reading the FAQ confirms this. Assuming there was connection pooling was
clearly a bad assumption on my part. We don't use spring internally, so we
have no pre-built components available to handle connection pooling. For
now, I'm going to deal with it by simply moving away from transactional
message processing, and immediately acknowledging every message when it is
received. I'll deal with the consequences of failing message handlers
later.
I was also consuming messages in a very different fashion last time I used a
non-transactional method, so perhaps this change in combination with that
previous change will get my system into working order. Once again, I'll
post back here with the results of these changes.
If you notice any flaw in my reasoning, please do tell me. :)
Thanks,
Bryan
On Thu, Aug 28, 2008 at 4:30 PM, Bryan Murphy <bm...@gmail.com> wrote:
> Hi Jim,
>
> We're currently using transactional messages. What we do is the following:
>
> - create connection factory
> - create session (acknowledgement mode = transactional)
> - create consumer
> - bind handler to consumer.Listener
>
> in the handler we do the following:
>
> - handle message
> - grab reference to session (stored as an instance variable)
> - commit session if sucess, rollback if failure
>
> If we were to switch from transactional to client acknowledge, then I would
> understand calling message.Acknowledge(). If for some reason we failed to
> handle the message, how should we deal with it? Should we pop it back into
> the queue and then call acknowledge? Call acknowledge and then pop it back
> into the queue? Or do something else entirely? :)
>
> Anyway, I'll play around with the acknowledge method and post back here if
> I have any success. We were originally using "auto acknowledge" and not
> explicitly calling acknowledge on the message before we switched over to
> handling them transactionally.
>
> Thanks,
> Bryan
>
> On Thu, Aug 28, 2008 at 3:42 PM, semog <e....@gmail.com> wrote:
>
>>
>> Hi Bryan,
>>
>> I can't get to your source code examples. My work internet is filtering
>> out
>> that site. So, I would first check to make sure that you are calling
>> Acknowledge on the received messages. It may be that the Broker is
>> stopping
>> the send to your clients, because it thinks they are "slow" (i.e., they
>> have
>> not responded to the messages it has already sent to them).
>>
>> Best,
>> Jim
>>
>>
Re: ActiveMQ + NMS = Stalled Message Queues
Posted by Bryan Murphy <bm...@gmail.com>.
Hi Jim,
We're currently using transactional messages. What we do is the following:
- create connection factory
- create session (acknowledgement mode = transactional)
- create consumer
- bind handler to consumer.Listener
in the handler we do the following:
- handle message
- grab reference to session (stored as an instance variable)
- commit session if sucess, rollback if failure
If we were to switch from transactional to client acknowledge, then I would
understand calling message.Acknowledge(). If for some reason we failed to
handle the message, how should we deal with it? Should we pop it back into
the queue and then call acknowledge? Call acknowledge and then pop it back
into the queue? Or do something else entirely? :)
Anyway, I'll play around with the acknowledge method and post back here if I
have any success. We were originally using "auto acknowledge" and not
explicitly calling acknowledge on the message before we switched over to
handling them transactionally.
Thanks,
Bryan
On Thu, Aug 28, 2008 at 3:42 PM, semog <e....@gmail.com> wrote:
>
> Hi Bryan,
>
> I can't get to your source code examples. My work internet is filtering
> out
> that site. So, I would first check to make sure that you are calling
> Acknowledge on the received messages. It may be that the Broker is
> stopping
> the send to your clients, because it thinks they are "slow" (i.e., they
> have
> not responded to the messages it has already sent to them).
>
> Best,
> Jim
>
>
Re: ActiveMQ + NMS = Stalled Message Queues
Posted by semog <e....@gmail.com>.
Hi Bryan,
I can't get to your source code examples. My work internet is filtering out
that site. So, I would first check to make sure that you are calling
Acknowledge on the received messages. It may be that the Broker is stopping
the send to your clients, because it thinks they are "slow" (i.e., they have
not responded to the messages it has already sent to them).
Best,
Jim
Bryan Murphy-4 wrote:
>
> Hey Guys,
> I'm new to ActiveMQ and am running into a problem that has me
> stumped. We're using NMS to communicate with an ActiveMQ message
> broker. After a random period of time our consumers stop receiving
> messages. Our producers do not seem to have any difficulty delivering
> messages.
>
> You can view the code we use to send our messages here:
> http://pastebin.com/f7e1a6dd3
>
> You can view the code we use to consume our messages here:
> http://pastebin.com/f2d146b3b
>
> We process the messages transactionally. I've put an obscene amount of
> tracing into our code, and as far as I can tell the consumers simply stop
> receiving messages. I can usually rectify the problem by restarting the
> stalled service, however, on occasion I actually have to restart the
> ActiveMQ message broker itself to get messages flowing again!
>
> Could somebody help me determine what I am doing wrong, or at least point
> me
> in the direction so I determine what the queues are blocking on?
>
> Additional Info:
> * ActiveMQ 5.1.0 (100% default configuration, download, untar, and run)
> * Java 1.6.0_06-b02
> * Ubuntu 8.04.1 (100% up to date) & Windows Server 2003
> * Mono 2.0p1 & Microsoft .NET Framework 3.5
> * Apache.NMS and Apache.NMS.ActiveMQ built from trunk as of yesterday
> * tcp://ADDRESS:61616 connect to broker (over public internet), no other
> options
>
> Thanks,
> Bryan
>
>
--
View this message in context: http://www.nabble.com/ActiveMQ-%2B-NMS-%3D-Stalled-Message-Queues-tp19207646p19208772.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.