activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "peter royal (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AMQ-1625) Producers hang when broker is fubar
Date Mon, 22 Dec 2008 17:23:05 GMT

    [ 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.


Mime
View raw message