> What would the callback do? (and what would it do if it reported an
> exception?)
The callback would inform you that the message is being accepted by the server.
There's nothing to be done In case you reported an exception.
That would be the same as you reporting an exception on this following example
public void someFunction()
{
producer.send(msg); // it will block here
insertJDBCRecord(...); // If you reported an exception here, the
message has been accepted already
}
In cases where the user needs rollbacks and exception treatment for
the rollback purpose the user will just use the transactioned session.
>
> Would the callback have any need to access the Message object? If so, what
> for?
I don't think so. Some users may find it more useful though.
>
> Do you see any need for any thread to block until the callback is received?
>
That's really up to the implementation. I don't think there's any
need. A smart implementation would take care of it at the protocol
parsing layer.
There could be an implementation doing this with a blocking threads
receiving confirmations.. but that should really be an implementation
decision.
>
>> This will be useful for other scenarios such as completing other tasks
>> after the non-blocked operation has finished.
>>
>> From what I have seen, the non blocking approach from node.js is a new
>> trend, and I believe this sort of feature will be useful to support
>> that style of non-blocking programming.
>
>
> I agree. Note I'm not questioning a non-blocking send as a feature - I'm
> just checking that the notification API we've agreed on is appropriate for
> the use likely cases.
>
Maybe we should support a failed method on the interface as well?
> Thanks,
>
> Nigel