Re: net.jini.io.context.AcknowledgmentSource surprise

On Fri, Aug 10, 2007 at 03:28:48PM +0200, Mark Brouwer wrote:
> While debugging a server context I stumbled into the following server
> context element net.jini.io.context.AcknowledgmentSource which was
> completely new to me. Looking into the javadoc what its purpose is I
> read the following:
>
>   "A server context element for registering interest in receiving an
>    acknowledgment that the remote call's result data has been
>    delivered to and processed by the client."
>
> To be honest I'm quite pleasantly surprised because I've been coding my
> own confirmation logic in the past while it seems it was there all the
> time, this is something really useful and also different than what one
> can code himself. It might have had a reference in
> ServerContext.getServerContext as there is for ClientHost and
> ClientSubject because that way I would have certainly discovered it.

I think that we didn't expect it to be very broadly useful (like
compared to ClientHost or ClientSubject)-- it exists to support JERI's
DGC mechanism (see BasicObjectEndpoint.writeObject).

> Looking further at the method javadoc for the Listener one should
> register with an AcknowledgmentSource I read:
>
>   "Handles either receipt of an acknowledgment that the remote call's
>    result data has been processed by the client or an indication that no
>    acknowledgment will be received.
>
>   If received is true, then a positive acknowledgment has been received
>   that the remote call's result data has been processed by the client.
>   If received is false, then the implementation of this interface has
>   determined that no positive acknowledgment for the associated data
>   will be received (perhaps due, for example, to connection failure or
>   timeout)."
>
> From the above it is not clear (to me) whether an invocation made by the
> client resulting in e.g. a ServerException as result of (un)marshalling
> the result of the invocation results in true or false being passes in
> for the notification.

The "result data" quoted above is meant to refer to either a normal or
an exceptional result at the invocation level, so failures at the
level of (un)marshalling would still cause true to be passed.  False
indicates a lower-level communication problem, like with the client
side while processing the result or the server side not being able to
determine that the client processed the result.  For another
perspective, this flag basically corresponds to the positive
vs. negative acknowledgment distinction in the discussion of the
"ackRequired" flag of the "Data" message here:

http://java.sun.com/products/jini/2.1/doc/api/net/jini/jeri/connection/doc-files/mux.html

although this API is meant to be applicable to HTTP and other JERI
transport providers too.

> Another point is that there is no mentioning of whether the notification
> of the listeners takes place from the same thread as (was) handling the
> remote method invocation or that it can be dispatched to a thread pool.
> If that is up to the implementation it doesn't harm to make this more
> explicit in the spec.

I agree that the spec should be more explicit about this.

-- Peter

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]