[
https://issues.apache.org/activemq/browse/AMQNET-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59092#action_59092
]
Timothy Bish commented on AMQNET-247:
-------------------------------------
The behaviour is consistent with the Java client's implementation. It might
make more sense to throw an exception in this case since this setting really
indicates that some boundary condition you configured was exceeded. When the
send timeout occurs you are not sure whether the message was indeed sent so an
exception might be more appropriate, since while it is possible for the message
to eventually get acked by the broker its also possible the connection could
get broken or the broker could go down, who knows.
The producer window size stuff isn't completely implemented in NMS yet as far
as I know, its a bit tricky because of the issue with matching the reported
message size on the client with that of the broker, there's usually a small
difference if I remember correctly, so it needs some more work.
> 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.
