Issue 1722: New stream based stubs and location forward (java-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: The new portable stream-based stubs for the Java language mapping do not properly handle location forwards properly. The ORB must be able to give some indication to the ORB that it must remarshal in case the ORB receives a locate forward or object forward message. The remarshalling is required because the object key in the request message may have changed and the alignment will be incorrect. Resolution: closed issue Revised Text: Actions taken: July 22, 1998: received issue July 30, 1998: closed issue Discussion: End of Annotations:===== Return-Path: Sender: "George Scott" Date: Wed, 22 Jul 1998 09:53:38 -0700 From: "George M. Scott" Organization: Inprise Corporation To: java-rtf@omg.org CC: issues@omg.org, java2idl-rtf@omg.org Subject: New stream based stubs and location forward The new portable stream-based stubs for the Java language mapping do not properly handle location forwards properly. The ORB must be able to give some indication to the ORB that it must remarshal in case the ORB receives a locate forward or object forward message. The remarshalling is required because the object key in the request message may have changed and the alignment will be incorrect. To correct this problem we proposed the following: A new exception is defined as follows: package org.omg.CORBA.portable; final public class RemarshalException extends Exception { public RemarshalException() { super(); } } The invoke method as defined in ObjectImpl and Delegate is changed as follows: ObjectImpl: public InputStream _invoke(OutputStream os) throws ApplicationException, RemarshalException { return _get_delegate().invoke(this, os); } Delegate: public InputStream invoke(org.omg.CORBA.Object self, OutputStream os) throws ApplicationException, RemarshalException { throw new org.omg.CORBA.NO_IMPLEMENT(); } The following text will be added to the spec in the portable stub section: Stubs which use the stream-based model must catch the RemarshalException which is potentially thrown from the _invoke method of ObjectImpl. Upon catching the exception, the stub must immediately remarshal the request by calling _request, marshalling the arguments (if any) and then calling _invoke. The stub must repeat this process until _invoke returns normally or raises some exception other than RemarshalException. George Return-Path: X-Sender: ccaffrey@eng-mail Date: Wed, 22 Jul 1998 18:43:25 +0100 To: "George M. Scott" From: Colm Caffrey Subject: Re: New stream based stubs and location forward Cc: java2idl-rtf@omg.org, java-rtf@omg.org George, I believe IIOP 1.2 has made changes to avoid having to remarshal a request if the object key length changes after a locate forward exception. The request header and body are now aligned separately. This means that we should not need the changes suggested below. Cheers, Colm. At 09:53 22/07/98 -0700, George M. Scott wrote: >The new portable stream-based stubs for the Java language mapping >do not properly handle location forwards properly. The ORB must >be able to give some indication to the ORB that it must remarshal >in case the ORB receives a locate forward or object forward message. >The remarshalling is required because the object key in the request >message may have changed and the alignment will be incorrect. > >To correct this problem we proposed the following: > >A new exception is defined as follows: > >package org.omg.CORBA.portable; > >final public class RemarshalException extends Exception { > > public RemarshalException() { > super(); > } > >} > >The invoke method as defined in ObjectImpl and Delegate is changed >as follows: > >ObjectImpl: > > public InputStream _invoke(OutputStream os) > throws ApplicationException, RemarshalException { > return _get_delegate().invoke(this, os); > } > >Delegate: > > public InputStream invoke(org.omg.CORBA.Object self, OutputStream os) > throws ApplicationException, RemarshalException { > throw new org.omg.CORBA.NO_IMPLEMENT(); > } > >The following text will be added to the spec in the portable stub section: > >Stubs which use the stream-based model must catch the RemarshalException >which is potentially thrown from the _invoke method of ObjectImpl. Upon >catching the exception, the stub must immediately remarshal the request by >calling _request, marshalling the arguments (if any) and then calling >_invoke. The stub must repeat this process until _invoke returns normally >or raises some exception other than RemarshalException. > >George > > Return-Path: Sender: "George Scott" Date: Wed, 22 Jul 1998 15:45:17 -0700 From: "George M. Scott" Organization: Inprise Corporation To: Colm Caffrey CC: java2idl-rtf@omg.org, java-rtf@omg.org Subject: Re: New stream based stubs and location forward References: <3.0.32.19980722184325.00913140@eng-mail> Colm Caffrey wrote: > > George, > > I believe IIOP 1.2 has made changes to avoid having to remarshal a > request if the object key length changes after a locate forward > exception. The request header and body are now aligned separately. > This means that we should not need the changes suggested below. Agreed, but we would like to be able to have our stubs speak any version of IIOP, not just 1.2. So for that reason I think this is a necessary change. George Date: Thu, 18 Mar 1999 17:15:30 GMT From: Nick Reeves To: java-rtf@omg.org, gscott@inprise.com cc: issues@omg.org, java2idl-rtf@omg.org Subject: Re: issue 1722 New stream based stubs and location forward The original issue states that remarshalling may be required in the case of location forward because the object key may have changed and the alignment may be incorrect. In fact the change of alignment can be handled without remarshalling because of the following observation which I have implemented successfully as an optimization for other reasons. Each alignment restriction 1, 2, 4, 8 divides into the next higher one (since they are powers of 2). Thus any group of marshalled data items where the alignment restriction of the first one is not exceeded by any of the following ones can always be moved as a block. Thus the only problems can occur at the points where the alignment restriction increases. There can be at most three of these: 1 -> 2 2 -> 4 4 -> 8. With the information on where the alignment restriction increases are the data can be changed to a different alignment by changing the padding at these points. It is sufficient to record the index in the marshalling buffer before the first output (and it's alignment padding) at alignment n or more for n = 2, 4, 8. This can be efficiently implemented by combining the check for first output at alignment n or more, with the output buffer growing check, by keeping a separate buffer length for output at each of the alignments 1, 2, 4, 8, and initially setting the buffer lengths for alignments other than 1 to be -1, so that it will be exceeded on first output. -- Nick Reeves