[
https://issues.apache.org/activemq/browse/AMQ-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=48311#action_48311
]
peter royal commented on AMQ-1625:
----------------------------------
Thanks for the followup, Gary.
I believe they were all sharing a session, but I don't recall anymore (this was
at a project with a past employer, and I don't have access to the test code
anymore).
iirc, the test was to a persistent queue, so a slow consumer shouldn't block
producers. If the consumer is slow the messages would spool to disk.
You can probably close this for now.. but my thought at the time was using the
method that took a timeout would help prevent blocking forever for unsuspecting
users. Even if the default was several minutes, if its blocked for that long,
things are likely fubar.
> 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
> Fix For: 5.3.0
>
> 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.
