Clebert,
On 18/05/2012 19:18, Clebert Suconic wrote:
>> 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.
What I mean is: do you see any need for the application thread that called send() to block at some later stage whilst it
waited for confirmation that the acknowledgement had been received?
The application would do this:
1. Call the async send
2. Perform some other work whilst waiting for the send to be completed
3. Block until confirmation is received that the send has been completed
I gave a example of such an application in my email on 17th May, in which the application called wait() to wait until
the callback method was invoked, which called notify() to wake up the waiting thread. Do you (or anyone else) see any
need for this?
If an application does need to be able to do this, does it need to be made easier for applications to code?
> 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?
>
There already is:
http://jms-spec.java.net/2.0-SNAPSHOT/apidocs/javax/jms/CompletionListener.html#onException%28java.lang.Exception%29
void onException(Exception exception)
Notifies user that the specified exception was thrown while attempting to send the message
Nigel