On 10/6/06, Hiram Chirino <[EMAIL PROTECTED]> wrote:
On 10/5/06, John Heitmann <[EMAIL PROTECTED]> 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
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/BlockingQueue.html#offer(E,%20long,%20java.util.concurrent.TimeUnit)
to avoid blocking the calling thread too long then failing if the
timeout expires.
--
James
-------
http://radio.weblogs.com/0112098/
