You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "peter royal (JIRA)" <ji...@apache.org> on 2008/03/22 19:27:32 UTC

[jira] Commented: (AMQ-1625) Producers hang when broker is fubar

    [ https://issues.apache.org/activemq/browse/AMQ-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=41757#action_41757 ] 

peter royal commented on AMQ-1625:
----------------------------------

i was able to reproduce this by having 10 threads share a session, all sending messages to the same queue 0..100ms between sends. it failed after a few thousand messages. restarting the broker fixes the problem. the producer and broker were separate VM's.

i then tried the trunk snapshot from 3/18, and the same test program worked fine.

i can modify my test to see if it can happen with everything in the same VM, so a unit test can be created (if there is interest from the AMQ developers).

i did a cursory review of the changes between 1/16 and 3/18 and nothing jumped out. are there any notable concurrency related bugs that were fixed in this time?

> Producers hang when broker is fubar
> -----------------------------------
>
>                 Key: AMQ-1625
>                 URL: https://issues.apache.org/activemq/browse/AMQ-1625
>             Project: ActiveMQ
>          Issue Type: Bug
>    Affects Versions: 5.1.0
>         Environment: SNAPSHOT build from 1/16/08
>            Reporter: peter royal
>         Attachments: hung producers.log
>
>
> see attached log.
> in a nutshell,
> Transport.request(Object command) is dangerous, and shouldn't be used.
> Transport.request(Object command, int timeout) should be used instead.
> something happened to my broker (don't know what yet), and it caused the producer to hang as seen. then since the session is shared, a bunch of other threads blocked as well. if the request on the transport had a timeout (this is to catch failure scenarios, so something that's not expected to reasonably happen), things would have errored out rather than building waiting threads.
> if it is amiable, i can produce a patch that will remove the non-timeout'd version of Transport.request() and use the version with a timeout everywhere.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.