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.