activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <>
Subject Re: Hang on publish of non-persistent message
Date Fri, 06 Oct 2006 00:52:49 GMT
On 10/5/06, John Heitmann <> wrote:
> On Oct 5, 2006, at 6:40 AM, nbreau wrote:
> > I'm not sure if this issue is related.... my issue occurs randomly,
> > within
> > the first 50-100 messages that get sent, and it's only a single
> > producer
> > that hangs, but over time all my producer threads would become hung.
> >
> > Is there some kind of timeout i can apply to a publish call ?
> Unfortunately the useAsyncSend setting doesn't have the entire
> semantic you might expect. At the lowest level it will still perform
> synchronous network operations in the same thread as your publish.
> This means that if there's a TCP backlog (because of a slow network,
> down network, throttling broker, buggy broker, etc. etc.) then even
> the async send can block.
> One thing to check would be to connect to your broker with JMX and
> look at the thread handling the hung connection and see if and where
> it's blocked. If it's blocked on the UsageManager then you need to
> either raise your UsageManager memory limit or turn on the new non-
> blocking UsageManager flag.
> If it's not blocked on the UsageManager then you're probably hitting
> an unknown problem. If you could find the blockage and let us know
> where it is that would rock (assuming it's not just a problem on your
> network).
> I've got a transport filter I've been meaning to submit that sits in
> front of almost all other transport filters and provides true
> asynchronous sending by adding a tiny client-side queue. This helps
> avoid bugs in transport code, hitches in the network, and hitches in
> the broker that could otherwise lead to publish blocking. I'll get
> that dusted off and published. The downside to it is that it means
> publishes are 100% unthrottled, which can easily lead to dropped
> messages if you publish too fast (it throws and exception so you know
> what's happening at least).

Awesome Idea.  Please send us the patch!

Hopefully when you submit the patch it will add a sendBufferSize
property.  Where it's value helps us configure if a send is 'truely
async' or not.
The sendBufferSize would be the the maximum number of messages that
will buffer for your 'true' async sends.  This setting should default
to 0 and in essence disable 'true' async sends.  It should be a
property on both the connection factory and the connection.

And hopefully it also has a sendTimeout property on the connection
factory, connection, and producer destination option.  It would only
be used if 'true' async sends are being used and it values should work
something like:
if sendTimeout=0 then sends block until more space is available (like
we do today).
if sendTimeout<0 then if the client side send buffer is full, we throw
and exception right away
if sendTimeout>0 then the send waits at least sendTimeout ms
attempting to get space on that buffer before throwing a timeout.

> John



View raw message