NMS library hangs when connection to ActiveMQ is broken

[jeetukiran]

The NMS API calls to send and receive messages synchronously hang when the connection to ActiveMQ gets broken, the expections are not relayed back to the caller.

[semog]

I am currently taking a look at this.  Part of the solution is to set
a timeout for your transport using a URI parameter like so:

activemq:tcp://amqsrv:61616?transport.requesttimeout=10000

Where requesttimeout is in milliseconds.  However, there is a bug with
the timeout, because it will continuously retry after the timeout
expires. I hope to have a fix for this soon.



On 4/2/08, jeetukiran <jeetu@...> wrote:

>
> The NMS API calls to send and receive messages synchronously hang when the
> connection to ActiveMQ gets broken, the expections are not relayed back to
> the caller.
> --
> View this message in context:
> http://www.nabble.com/NMS-library-hangs-when-connection-to-ActiveMQ-is-broken-tp16452218s2354p16452218.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>

[Oleg Deribas-5]

Jim Gomes wrote:

> I am currently taking a look at this.  Part of the solution is to set
> a timeout for your transport using a URI parameter like so:
>
> activemq:tcp://amqsrv:61616?transport.requesttimeout=10000

Thanks Jim. BTW, is there any place (possibly in the source code) where
all possible URI parameters are documented?

--
Oleg

[semog]

Well, they say that the sourcs code itself is the ultimate
documentation. :). But in this regard, there is not a single location
that lists all possible URI parameters for the .NET client in a single
location.  I think the Java client is documented, and we try to stay
compatible, but I know there are some differences.

I usually have to search through the source code to find them. I think
it would be very worthwhile to place some attention on improving the
documentation in this area. Both to document what NMS has and how it
differs from the Java client.




On 4/3/08, Oleg Deribas <thisaddressisnotmine@...> wrote:

> Jim Gomes wrote:
>
> > I am currently taking a look at this.  Part of the solution is to set
> > a timeout for your transport using a URI parameter like so:
> >
> > activemq:tcp://amqsrv:61616?transport.requesttimeout=10000
>
> Thanks Jim. BTW, is there any place (possibly in the source code) where
> all possible URI parameters are documented?
>
> --
> Oleg
>
>

[semog]

I have checked in a fix for the timeout looping issue.  I have more
changes coming, but I felt that these changes were important enough to
get checked in as soon as possible.  Dealing with error handling code
is difficult. If anyone having this particular problem would care to
get the latest trunk code and test it out, that would be appreciated.

Remember to set the transport.requesttimeout value in your connection URI.

If you find any problems, please attach any comments to [AMQNET-81].

-Jim



On 4/3/08, Jim Gomes <e.semog@...> wrote:

> I am currently taking a look at this.  Part of the solution is to set
> a timeout for your transport using a URI parameter like so:
>
> activemq:tcp://amqsrv:61616?transport.requesttimeout=10000
>
> Where requesttimeout is in milliseconds.  However, there is a bug with
> the timeout, because it will continuously retry after the timeout
> expires. I hope to have a fix for this soon.
>
>
>
> On 4/2/08, jeetukiran <jeetu@...> wrote:
> >
> > The NMS API calls to send and receive messages synchronously hang when the
> > connection to ActiveMQ gets broken, the expections are not relayed back to
> > the caller.
> > --
> > View this message in context:
> >
> http://www.nabble.com/NMS-library-hangs-when-connection-to-ActiveMQ-is-broken-tp16452218s2354p16452218.html
> > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> >
> >
>

[Michael Franz]

semog wrote:

I have checked in a fix for the timeout looping issue.  I have more
changes coming, but I felt that these changes were important enough to
get checked in as soon as possible.  Dealing with error handling code
is difficult. If anyone having this particular problem would care to
get the latest trunk code and test it out, that would be appreciated.

Remember to set the transport.requesttimeout value in your connection URI.

If you find any problems, please attach any comments to [AMQNET-81].

-Jim

I was having the same issue.  Based on what I was seeing I tried to setting connection parameters based on this documentation http://activemq.apache.org/tcp-transport-reference.html it did not work.  Following the recommendations here, my problem is solved.  

I had updated to HEAD and tried that first before using the transport.requesttimeout parameter.  HEAD by itself did not solve the problem.  However, I don't know if using transport.requesttimeout solved the problem without the code changes.

What I did find while trying to figure out the problem, is:
- debugging through the NMS code caused the problem to go away.  
- it was only reproducible when I ran the produce.Send method.
- not all of the connection parameters are documented, thus making the choice of configuration changes very limited.

To summarize my issue:
- I have a producer that was working fine until the connection was lost
- if the connection was down and I tried to send from the producer the thread that was sending the message would hang - forever.
- the thread that received the connection exception worked fine, but was not my business logic thread
- this seemed very much like a thread deadlock issue.  A coworker suggested that it was a socket timeout issue, however I was not able to configure the connection with the documentation I could find
- my issued has been resolved (for now) by using transport.requesttimeout=10000

Michael