[
https://issues.apache.org/activemq/browse/AMQNET-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=58734#action_58734
]
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 deal.
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();
cf.setProducerWindowSize(1024000);
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: https://issues.apache.org/activemq/browse/AMQNET-247
> 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.
