activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Hang on publish of non-persistent message
Date Fri, 06 Oct 2006 07:12:55 GMT
On 10/6/06, Hiram Chirino <> wrote:
> 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!

Agreed - and that Jedi patch too :)

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

Yeah. I guess using a BlockingQueue and offer() in the calling thread
then a separate thread doing the actual writing to the socket. Then
the caller thread could use a timeout based offer,%20long,%20java.util.concurrent.TimeUnit)

to avoid blocking the calling thread too long then failing if the
timeout expires.



View raw message