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! 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
-- Regards, Hiram Blog: http://hiramchirino.com
