JDK-5092823 : The javadoc UnmarshalException don't elaborate on semantics
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.rmi
  • Affected Version: 5.0
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: solaris_2.5.1
  • CPU: x86
  • Submitted: 2004-08-26
  • Updated: 2013-10-25
Related Reports
Relates :  
JDK-4671925 - (spec) ServerException cannot be thrown if there is a problem marshalling return
Relates :  
JDK-4849488 - (fmspec) spec should mention "at most once" call semantics
Description

Name: rmT116609			Date: 08/26/2004


A DESCRIPTION OF THE PROBLEM :
The javadoc on MarshalException states:

If a MarshalException occurs during a remote method call, the call may or may not have reached the server. If the call did reach the server, parameters may have been deserialized. A call may not be retransmitted after a MarshalException and reliably preserve "at most once" call semantics.

However the javadoc for UnmarshalException does not elaborate on this.


URL OF FAULTY DOCUMENTATION :
http://java.sun.com/j2se/1.4.2/docs/api/java/rmi/UnmarshalException.html
(Incident Review ID: 300973) 
======================================================================
Comments
EVALUATION The intended implication is that the same property applies: (absent further knowledge) a remote call must not be retransmitted after an UnmarshalException has occurred while attempting to preserve a guarantee of "at-most-once" semantics. This issue could be clarified for UnmarshalException, as well as for other RemoteException subclasses. This bug is somewhat related to 4849488 because of the desire to clarify the meaning of RMI's guarantee of "at-most-once" invocation semantics. [Incidentally, the statement that a MarshalException is thrown if an IOException occurs while marshalling the return value (or more generally, result) of a remote method call is potentially confusing, because while that is indeed what happens on the server side, the client will never see such a MarshalException because of the issue described in 4671925.] ###@###.### 2004-08-30
30-08-2004