activemq-dev mailing list archives

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

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

Gary Tully commented on AMQ-1625:
---------------------------------

This looks like a case of  'slow consumer' and producer flowcontrol. You can fail producers,
block them or spool to disk. The default out of the box 5.2 behavior is to use producer flow
control and stall/block the producer. The SystemUsage.setSendFailIfNoSpace attribute can force
a failure and configuring a memory limit for message spooling can ensure memory limits are
not exceeded.

In your test case, it is 10 threads sharing a connection rather than a session, correct?.
A session should be reserved for a single thread.

I am wondering if this issue can be closed or if you want an additional facility to enable
fail with timeout when producer flow control is configured.

> 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