activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Gellings (JIRA)" <>
Subject [jira] Commented: (AMQNET-247) Bug in FutureResponse on how handles timeout
Date Fri, 09 Apr 2010 16:07:08 GMT


Mark Gellings commented on AMQNET-247:

I've actually looked into this a bit more and think I understand why just the TODO comment
was left with a ? mark.  If the broker activated flow control (provided default window size
is not active on the client), then we can't assume the message didn't get to the broker. 
The ResponseCorrelator actually operates on a seperate thread and is listening for an acknowledgement
that the broker received the message.

So bottom line, if we timed out and indicated the message didn't reach the broker then that
also may be misleading, because eventually the response may come back and the message may
have been delivered.  

In our scenario it seems when the broker activates flow control, a deadlock occurs.  At that
point our system under test freezes up.  Apparently a deadlock is possible if going by the
ActiveMQ in Action book, which is what we assume is occurring (book excerpt below).

So I think it comes down to two possible solutions:

1) Activate producer flow control the preferrably way (through the producer window size setting
on the producer end).  Theoretically though if one had enough producers the broker could still
activate flow control and the suspected deadlock could occur.
2) Disable flow control altogether.  We are using jdbc master/slave so we aren't too concerned
about processing speed anyway.  If messages don't get stored in memory it isn't a real big

Do you have any thoughts on this Tim?  Does this all make sense to you? 

Example 13.10. Setting the producer window size
ActiveMQConnectionFactory cf = new ActiveMQConnectionFactory();

The producerWindowSize is the number bytes allowed in the producers send
buffer before it will be forced to wait for a receipt from the broker that it is still
within its limits.
If this isn't enabled for an asynchronous publisher, the broker will still pause
message flow, defaulting to simply blocking the message producers transport
(*which is inefficient and prone to deadlocks*).

> Bug in FutureResponse on how handles timeout
> --------------------------------------------
>                 Key: AMQNET-247
>                 URL:
>             Project: ActiveMQ .Net
>          Issue Type: Bug
>          Components: NMS
>    Affects Versions: 1.2.0
>            Reporter: Mark Gellings
>            Assignee: Jim Gomes
> In FutureReponse.cs, in the Response getter if !latch.awaite(maxWait) times out a timeout
exception should be thrown.  Currently there is just a TODO comment.  
> This is a bug because when it is not thrown the producer thinks the message was sent
successfully when actually it wasn't.  This could be problematic to any system if a message
really isn't sent.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message