activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Bish (JIRA)" <>
Subject [jira] Commented: (AMQNET-247) Bug in FutureResponse on how handles timeout
Date Mon, 26 Apr 2010 12:53:25 GMT


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:
>             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