Issue 4289: GIOP issue : fragmented replies with exceptions (interop) Source: Oracle (Mr. Ram Jeyaraman, nobody) Nature: Uncategorized Issue Severity: Summary: Let us assume that the server has sent a few reply fragments. But before sending all the reply fragments, an exception occurs (say while marshalling the response). What does the server and the client (which has already seen reply fragments) do ? Just to note, notice that if the same problem happens while the client is in the midst of sending request fragments, the client can choose to send a CancelRequest message to intimate the server. Since there are various possible behaviours for the client and server, the GIOP specification needs to clarify the standard behaviour, in order for different implementations to remain interoperable. One possible behaviour : The server could send back a seperate response (containing the exception with CompletionStatus.COMPLETED_YES). The client on receipt of the new reply, and noticing the fact that another reply with the same requestId is pending, could discard the pending reply and process the latest reply. Another behaviour : The client could simply timeout the request and discard any new reply streams (with the same requestId), and raise an exception with CompletionStatus.COMPLETED_MAYBE. Resolution: This issue is resolved by the resolution to issue 4273. Revised Text: Actions taken: April 30, 2001: received issue May 13, 2002: closed issue Discussion: End of Annotations:===== Date: Mon, 30 Apr 2001 10:33:51 -0700 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: interop@omg.org CC: issues@omg.org Subject: GIOP issue : fragmented replies with exceptions Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: b32!!p&!!!*4S!!ha-e9 Re : GIOP 1.2 Let us assume that the server has sent a few reply fragments. But before sending all the reply fragments, an exception occurs (say while marshalling the response). What does the server and the client (which has already seen reply fragments) do ? Just to note, notice that if the same problem happens while the client is in the midst of sending request fragments, the client can choose to send a CancelRequest message to intimate the server. Since there are various possible behaviours for the client and server, the GIOP specification needs to clarify the standard behaviour, in order for different implementations to remain interoperable. One possible behaviour : The server could send back a seperate response (containing the exception with CompletionStatus.COMPLETED_YES). The client on receipt of the new reply, and noticing the fact that another reply with the same requestId is pending, could discard the pending reply and process the latest reply. Another behaviour : The client could simply timeout the request and discard any new reply streams (with the same requestId), and raise an exception with CompletionStatus.COMPLETED_MAYBE. thanks, Ram Sender: jon@corvette.floorboard.com Message-ID: <3AEDE320.25D9B99D@floorboard.com> Date: Mon, 30 Apr 2001 15:11:44 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ram Jeyaraman CC: interop@omg.org, issues@omg.org Subject: Re: GIOP issue : fragmented replies with exceptions References: <3AEDA1FF.6DD9E505@eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 7>F!!<8;!!0cUd9;8:!! Ram Jeyaraman wrote: > Let us assume that the server has sent a few reply fragments. But before sending all the reply > fragments, an exception occurs (say while marshalling the response). > What does the server and the client (which has already seen reply fragments) do ? > > Just to note, notice that if the same problem happens while the client is in the midst of sending > request fragments, the client can choose to send a CancelRequest message to intimate the server. > > Since there are various possible behaviours for the client and server, the GIOP specification needs > to clarify the standard behaviour, in order for different implementations to remain interoperable. > > One possible behaviour : > > The server could send back a seperate response (containing the exception with > CompletionStatus.COMPLETED_YES). The client on receipt of the new reply, and noticing the fact that > another reply with the same requestId is pending, could discard the pending reply and process the > latest reply. > > Another behaviour : > > The client could simply timeout the request and discard any new reply streams (with the same > requestId), and raise an exception with CompletionStatus.COMPLETED_MAYBE. Yup, this is a problem. It also exists in GIOP 1.1 in a more dangerous form. Since GIOP 1.1 does not support more than one fragmented message at a time, sending a non-fragment message when the last message specified that more fragments were coming is probably going to be treated as a protocol error, causing a MessageError response and an aborted connection. Timeouts probably won't work either, since the GIOP 1.1 engine is unlikely to have a separate fragment timeout and just treat the a timeout as a failed connection as well. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 01 May 2001 02:29:26 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Ram Jeyaraman CC: interop@omg.org Subject: Re: GIOP issue : fragmented replies with exceptions References: <3AEDA1FF.6DD9E505@eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: `He!!Rapd9,<;!!?5i!! I would like to add another possible solution. If the server encounters such a marshalling error on preparing a response fragment it could send an empty final response fragment (more bit set to nomore with empty body). This would force a corresponding marshall system exception on the client side. Tom Rutt PS fragmentation has sure been a constant headache for the last four years or more! Ram Jeyaraman wrote: > > Re : GIOP 1.2 > > Let us assume that the server has sent a few reply fragments. But before sending all the reply > fragments, an exception occurs (say while marshalling the response). > What does the server and the client (which has already seen reply fragments) do ? > > Just to note, notice that if the same problem happens while the client is in the midst of sending > request fragments, the client can choose to send a CancelRequest message to intimate the server. > > Since there are various possible behaviours for the client and server, the GIOP specification needs > to clarify the standard behaviour, in order for different implementations to remain interoperable. > > One possible behaviour : > > The server could send back a seperate response (containing the exception with > CompletionStatus.COMPLETED_YES). The client on receipt of the new reply, and noticing the fact that > another reply with the same requestId is pending, could discard the pending reply and process the > latest reply. > > Another behaviour : > > The client could simply timeout the request and discard any new reply streams (with the same > requestId), and raise an exception with CompletionStatus.COMPLETED_MAYBE. > > thanks, > Ram -- Tom Rutt Tel: +1 732 949 7862 Lucent Technologies Fax: +1 732 949 1196 Global Strategic Standards Email: terutt@lucent.com Sender: jon@corvette.floorboard.com Message-ID: <3AEEF077.F370CDC4@floorboard.com> Date: Tue, 01 May 2001 10:20:55 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: terutt@lucent.com, interop@omg.org Subject: Re: GIOP issue : fragmented replies with exceptions References: <3AEDA1FF.6DD9E505@eng.sun.com> <3AEE57C6.7BE89A21@lucent.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: E`)e9f_>e92&4!!iLEe9 Tom Rutt wrote: > > I would like to add another possible solution. > > If the server encounters such a marshalling error on preparing a response > fragment > it could send an empty final response fragment (more bit set to nomore with > empty body). > > This would force a corresponding marshall system exception on the client side. Simple and elegant, and it should work with existing clients with no change. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 01 May 2001 13:01:32 -0700 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: terutt@lucent.com CC: Ram Jeyaraman , interop@omg.org Subject: Re: GIOP issue : fragmented replies with exceptions References: <3AEDA1FF.6DD9E505@eng.sun.com> <3AEE57C6.7BE89A21@lucent.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: R[F!!SVcd9#CO!!"O'!! Tom's solution seems the best, except there will be a loss of some useful information (the actual exception). This issue / expected resolution could possibly be added to the _wish_list_ for the next revision of GIOP. thanks, Ram Tom Rutt wrote: > > I would like to add another possible solution. > > If the server encounters such a marshalling error on preparing a response > fragment > it could send an empty final response fragment (more bit set to nomore with > empty body). > > This would force a corresponding marshall system exception on the client side. > > Tom Rutt > > PS fragmentation has sure been a constant headache for the last four years or > more! > > Ram Jeyaraman wrote: > > > > Re : GIOP 1.2 > > > > Let us assume that the server has sent a few reply fragments. But before sending all the reply > > fragments, an exception occurs (say while marshalling the response). > > What does the server and the client (which has already seen reply fragments) do ? > > > > Just to note, notice that if the same problem happens while the client is in the midst of sending > > request fragments, the client can choose to send a CancelRequest message to intimate the server. > > > > Since there are various possible behaviours for the client and server, the GIOP specification needs > > to clarify the standard behaviour, in order for different implementations to remain interoperable. > > > > One possible behaviour : > > > > The server could send back a seperate response (containing the exception with > > CompletionStatus.COMPLETED_YES). The client on receipt of the new reply, and noticing the fact that > > another reply with the same requestId is pending, could discard the pending reply and process the > > latest reply. > > > > Another behaviour : > > > > The client could simply timeout the request and discard any new reply streams (with the same > > requestId), and raise an exception with CompletionStatus.COMPLETED_MAYBE. > > > > thanks, > > Ram > > -- > Tom Rutt Tel: +1 732 949 7862 > Lucent Technologies Fax: +1 732 949 1196 > Global Strategic Standards Email: terutt@lucent.com Date: Wed, 02 May 2001 00:16:43 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Ram Jeyaraman CC: interop@omg.org Subject: Re: GIOP issue : fragmented replies with exceptions References: <3AEDA1FF.6DD9E505@eng.sun.com> <3AEE57C6.7BE89A21@lucent.com> <3AEF161C.25A986A5@eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: *;>e9a;a!!J$V!!]'H!! Ram Jeyaraman wrote: > > Tom's solution seems the best, except there will be a loss of some useful information (the actual > exception). > Actually there is other missing information if the last segment is empty. In fact I would like to ammend my proposal to have the server send every octet which has been successfully marshalled for the reply in the last closing broken fragment. However, the client orb will know it has a marshalling exception due to incomplete information from the server (i.e. it runs out of octets in the last fragment before its marshalling engine is satisfied). The client orb could report this with a new minor code on marshalling minor code n : Incomplete final fragment recieved for giop response. Tom Rutt Date: Wed, 02 May 2001 07:50:18 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: terutt@lucent.com CC: Ram Jeyaraman , interop@omg.org Subject: Re: GIOP issue : fragmented replies with exceptions References: <3AEDA1FF.6DD9E505@eng.sun.com> <3AEE57C6.7BE89A21@lucent.com> <3AEF161C.25A986A5@eng.sun.com> <3AEF8A2B.26D1F06@lucent.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: JX4e9+DD!!o?-e9Y9j!! Hello Tom, It seems your suggestion of sending a last incomplete fragment if a marshaling error occurs after sending at least one good fragment is a good workaround (by workaround, I mean until an updated protocol could supply something like REPLY_CANCELLED which could carry an exception). Another possibility would be to close the connection, but that is too heavy-weight - effecting everyone using that connection instead of just the actual request. The incomplete last fragment should not be normative. What could be normative is to say that the client side shall see a marshaling exception with minor code N. Even then it may be a good idea to say that the client may see the "real" exception instead (in case other implementors come up with something clever). Thanks, Harold Date: Wed, 02 May 2001 11:08:55 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Harold Carr CC: Ram Jeyaraman , interop@omg.org Subject: Re: GIOP issue : fragmented replies with exceptions References: <3AEDA1FF.6DD9E505@eng.sun.com> <3AEE57C6.7BE89A21@lucent.com> <3AEF161C.25A986A5@eng.sun.com> <3AEF8A2B.26D1F06@lucent.com> <3AF01EAA.B039FEFB@sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 3@)e9L=Ke9k*`!!Cl3e9 Harold Carr wrote: > > Hello Tom, > > It seems your suggestion of sending a last incomplete fragment if a > marshaling error occurs after sending at least one good fragment is a > good workaround (by workaround, I mean until an updated protocol could > supply something like REPLY_CANCELLED which could carry an exception). > Another possibility would be to close the connection, but that is too > heavy-weight - effecting everyone using that connection instead of just > the actual request. > I think a reply cancelled with an error code on the wire would be nice for Giop 1.3. The minor code for the client orb to signal this kind of failure could be added without revving giop (ie old orbs do not need to send this to the app). > The incomplete last fragment should not be normative. I agree, but it sure would be disruptive if every server orb killed the connection in this case. I point out this is a valid alternative behaviour which mirrors the server situation into the client environment. The last fragment should not be empty, but should include all data which was successfully marshalled before the glitch. This give more info to the client orb. Tom Rutt -- Tom Rutt Tel: +1 732 949 7862 Lucent Technologies Fax: +1 732 949 1196 Global Strategic Standards Email: terutt@lucent.com Date: Wed, 02 May 2001 08:11:11 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: terutt@lucent.com CC: Ram Jeyaraman , interop@omg.org Subject: Re: GIOP issue : fragmented replies with exceptions References: <3AEDA1FF.6DD9E505@eng.sun.com> <3AEE57C6.7BE89A21@lucent.com> <3AEF161C.25A986A5@eng.sun.com> <3AEF8A2B.26D1F06@lucent.com> <3AF01EAA.B039FEFB@sun.com> <3AF02307.BCFDA633@lucent.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: :Og!!>@1!![>U!!5k(e9 Hello Tom, > The minor code for the client orb to signal this kind of failure could be added > without revving giop (ie old orbs do not need to send this to the app). I agree. We just need to come up with some words and a number. > The last fragment should not be empty, but should include all data which was > successfully > marshalled before the glitch. This give more info to the client orb. I agree. However I think that is a quality-of-implementation issue. I think the only thing required should be the marshaling exception with minor code N. Thanks, Harold Date: Mon, 04 Jun 2001 09:04:03 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Everett Anderson CC: interop@emerald.omg.org Subject: Re: [Fwd: Re: Urgent Issue Vote 1 Interop Dec2000] References: <3B1831BE.12618911@sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: OXKe9>i~!!(`Ie9n:"!! Everett Anderson wrote: > > > Hi, > > I'm voting as a proxy for Harold Carr, who is on vacation. > > Sun votes YES to all resolutions in this vote except for 4289 -- > please > see reasoning below. > > > Issue 4289: GIOP issue : fragmented replies with exceptions > Vote: No > > As suggested in the discussion, we should provide a minor code for a > client to throw when a marshaling error occurs because it expected > more > data, but received a final fragment. Also, we should note that one > possible cause for that situation is that the server experienced a > marshaling error after already sending fragments of the reply to the > client. We can do this in GIOP 1.2. > > It sounds like we should also add a more complete solution to the > GIOP > 1.3 wish list, also suggested in the discussion archive. > > I thought that the minor code in the result was for that purpose. Are you asking for another wordsmithing round to get the detailed wording fixed up? -- ---------- Tom Rutt Tel: +1 732 949 7862 Global Strategic Standards Fax: +1 732 949 1192 Lucent Technologies terutt@lucent.com From: "Everett Anderson" To: Subject: FW: Vote 2 for Interop RTF (new proposal for Issue 4289 Date: Tue, 5 Jun 2001 00:28:40 -0700 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text/plain; charset="us-ascii" X-UIDL: U0)!!`Ol!!n^L!!,5_!! Hi, Sun votes YES to this proposed resolution for issue 4289. Thanks, Everett -----Original Message----- From: Tom Rutt [mailto:terutt@lucent.com] Sent: Monday, June 04, 2001 3:19 PM To: interop@omg.org Cc: terutt@lucent.com Subject: Vote 2 for Interop RTF (new proposal for Issue 4289 Interop Dec2000 RTF Vote 2: Closing Monday June11, 2001, 5:00 PM EDT Sorry, this is the proper proposed resolution for Issue 4259. Any votes in vote 1 on the erroneous proposal for 4259 are considered as withdrawn. Issue 4289: GIOP issue : fragmented replies with exceptions (interop) Click here for this issue's archive. Source: Sun Microsystems (Mr. Ram Jeyaraman, ram.jeyaraman@eng.sun.com) Nature: Uncategorized Issue Severity: Summary: Let us assume that the server has sent a few reply fragments. But before sending all the reply fragments, an exception occurs (say while marshalling the response). What does the server and the client (which has already seen reply fragments) do ? Just to note, notice that if the same problem happens while the client is in the midst of sending request fragments, the client can choose to send a CancelRequest message to intimate the server. Since there are various possible behaviours for the client and server, the GIOP specification needs to clarify the standard behaviour, in order for different implementations to remain interoperable. One possible behaviour : The server could send back a seperate response (containing the exception with CompletionStatus.COMPLETED_YES). The client on receipt of the new reply, and noticing the fact that another reply with the same requestId is pending, could discard the pending reply and process the latest reply. Another behaviour : The client could simply timeout the request and discard any new reply streams (with the same requestId), and raise an exception with CompletionStatus.COMPLETED_MAYBE. Discussion: If the server encounters such a marshalling error on preparing a response fragment it could send an empty final response fragment (more bit set to nomore with empty body). This would force a corresponding marshall system exception on the client side. Another acceptable behaviour would be to send an incomplete final response fragment, including only the parameters which were sucsessfully marshalled. A new minor code is needed for the client orb to signal this situation to the client applicaiton Resolution: To close with revision. Revised Text: Add the following new minor code to the table for system exceptions: System Exception Minor Code Description MARSHALL j+1 An incomplete final fragment was received for a fragmented response Actions taken: April 30, 2001: received issue Date: Tue, 05 Jun 2001 13:37:16 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: terutt@lucent.com Cc: interop@omg.org Subject: Re: Vote 2 for Interop RTF (new proposal for Issue 4289 References: <3B1C0949.350A7081@lucent.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 0G>e9~,7!!5i2e93f8e9 HP votes NO on this resolution 4289. I provides no guidance in the revised specification on how and when this new minor code should be used. There is a bit of discussion in the issue itself, but no proposed additional text reflecting any of that for inclusion in the standard. It is too much to expect people to have to go hunting through the issue resolutions to figure out what was in the back of peoples minds when they added a particular minor code. Jishnu. > Tom Rutt wrote: > > Sorry, I had brain fade and confused a short message error with an > incomplete > final fragment. > > Indeed, the Issue 4289 proposal should be considered withdrawn, with > this new > proposal to be > voted on as vote 2. > > The vote 2 closes on Monday, next week. > > ------- > > -- > ---------- > Tom Rutt Tel: +1 732 949 7862 > Global Strategic Standards Fax: +1 732 949 1192 > Lucent Technologies terutt@lucent.com > > --------------------------------------------------------------- > Interop Dec2000 RTF Vote 2: > > Closing Monday June11, 2001, 5:00 PM EDT > > Sorry, this is the proper proposed resolution for Issue 4259. > > Any votes in vote 1 on the erroneous proposal for 4259 are > considered > as > withdrawn. > > > > Issue 4289: GIOP issue : fragmented replies with exceptions > (interop) > > Click here for this issue's archive. > Source: Sun Microsystems (Mr. Ram Jeyaraman, > ram.jeyaraman@eng.sun.com) > Nature: Uncategorized Issue > Severity: > Summary: Let us assume that the server has sent a few reply > fragments. > But before sending all the reply fragments, an > exception occurs (say while marshalling the response). What does the > server and the client (which has already seen reply > fragments) do ? Just to note, notice that if the same problem > happens > while the client is in the midst of sending request > fragments, the client can choose to send a CancelRequest message to > intimate the server. Since there are various possible > behaviours for the client and server, the GIOP specification needs > to > clarify the standard behaviour, in order for different > implementations to remain interoperable. One possible behaviour : > The > server could send back a seperate response > (containing the exception with CompletionStatus.COMPLETED_YES). The > client on receipt of the new reply, and > noticing the fact that another reply with the same requestId is > pending, could discard the pending reply and process the > latest reply. Another behaviour : The client could simply timeout > the > request and discard any new reply streams (with the > same requestId), and raise an exception with > CompletionStatus.COMPLETED_MAYBE. > Discussion: > If the server encounters such a marshalling error on preparing a > response fragment > it could send an empty final response fragment (more bit set to > nomore > with empty body). > This would force a corresponding marshall system exception on the > client side. > > Another acceptable behaviour would be to send an incomplete final > response fragment, > including only the parameters which were sucsessfully marshalled. > > A new minor code is needed for the client orb to signal this > situation > to the client applicaiton > > Resolution: To close with revision. > Revised Text: Add the following new minor code to the table for > system > exceptions: > > System Exception Minor Code Description > MARSHALL j+1 An incomplete > final > fragment was received for a fragmented response > > Actions taken: > April 30, 2001: received issue > From: "Everett Anderson" To: Cc: Subject: RE: Vote 2 for Interop RTF (new proposal for Issue 4289 Date: Tue, 5 Jun 2001 16:36:09 -0700 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3B1D18CC.3F64710B@hp.com> Content-Type: text/plain; charset="us-ascii" X-UIDL: XNR!!d I provides no guidance in the revised specification on how and when this > new minor code should be used. There is a bit of discussion in the issue > itself, but no proposed additional text reflecting any of that for > inclusion in the standard. It is too much to expect people to have to go > hunting through the issue resolutions to figure out what was in the back > of peoples minds when they added a particular minor code. The description of meaning of the minor code is general, but the use is specific and clear -- whenever one unmarshals past the end of the stream (received the final fragment, but were expecting more data), throw a MARSHAL exception with the error code. It would be a little bit better if we could note that ONE of the possible causes for this situation is that the server received an exception after already sending some of the response fragments back to the client. Since it can occur due to several conditions, we can't specify one exact situation client-server scenario in the spec. For instance, if custom marshaling code tries to read too much, we would expect the same minor code, but it wouldn't have been caused by the server getting an exception. > > > > Tom Rutt wrote: > > > > Sorry, I had brain fade and confused a short message error with an > > incomplete > > final fragment. > > > > Indeed, the Issue 4289 proposal should be considered withdrawn, >with > > this new > > proposal to be > > voted on as vote 2. > > > > The vote 2 closes on Monday, next week. > > > > ------- > > > > -- > > ---------- > > Tom Rutt Tel: +1 732 949 >7862 > > Global Strategic Standards Fax: +1 732 949 1192 > > Lucent Technologies terutt@lucent.com > > > > >--------------------------------------------------------------- > > Interop Dec2000 RTF Vote 2: > > > > Closing Monday June11, 2001, 5:00 PM EDT > > > > Sorry, this is the proper proposed resolution for Issue 4259. > > > > Any votes in vote 1 on the erroneous proposal for 4259 are >considered > > as > > withdrawn. > > > > > > > > Issue 4289: GIOP issue : fragmented replies with exceptions >(interop) > > > > Click here for this issue's archive. > > Source: Sun Microsystems (Mr. Ram Jeyaraman, > > ram.jeyaraman@eng.sun.com) > > Nature: Uncategorized Issue > > Severity: > > Summary: Let us assume that the server has sent a few reply >fragments. > > But before sending all the reply fragments, an > > exception occurs (say while marshalling the response). What does >the > > server and the client (which has already seen reply > > fragments) do ? Just to note, notice that if the same problem >happens > > while the client is in the midst of sending request > > fragments, the client can choose to send a CancelRequest message >to > > intimate the server. Since there are various possible > > behaviours for the client and server, the GIOP specification needs >to > > clarify the standard behaviour, in order for different > > implementations to remain interoperable. One possible behaviour : >The > > server could send back a seperate response > > (containing the exception with >CompletionStatus.COMPLETED_YES). The > > client on receipt of the new reply, and > > noticing the fact that another reply with the same requestId is > > pending, could discard the pending reply and process the > > latest reply. Another behaviour : The client could simply timeout >the > > request and discard any new reply streams (with the > > same requestId), and raise an exception with > > CompletionStatus.COMPLETED_MAYBE. > > Discussion: > > If the server encounters such a marshalling error on preparing a > > response fragment > > it could send an empty final response fragment (more bit set to >nomore > > with empty body). > > This would force a corresponding marshall system exception on the > > client side. > > > > Another acceptable behaviour would be to send an incomplete final > > response fragment, > > including only the parameters which were sucsessfully marshalled. > > > > A new minor code is needed for the client orb to signal this >situation > > to the client applicaiton > > > > Resolution: To close with revision. > > Revised Text: Add the following new minor code to the table for >system > > exceptions: > > > > System Exception Minor Code Description > > MARSHALL j+1 An incomplete >final > > fragment was received for a fragmented response > > > > Actions taken: > > April 30, 2001: received issue > > > From: "Everett Anderson" To: , Cc: Subject: RE: Vote 2 for Interop RTF (new proposal for Issue 4289 Date: Wed, 6 Jun 2001 10:48:57 -0700 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3B1D18CC.3F64710B@hp.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text/plain; charset="us-ascii" X-UIDL: 6O$e9SREe9;`^d9Ynh!! Hi, Would the following slight amendment to the resolution for 4289 be sufficient? > > Revised Text: Add the following new minor code to the table for system > > exceptions: > > > > System Exception Minor Code Description > > MARSHALL j+1 An incomplete final > > fragment was received for a fragmented response and in CORBA formal 00-11-03 15.4.9 (Fragment Message) after the CancelRequest note but before the "A primitive data type of 8 bytes or smaller should never be broken across two fragments." paragraph add A MARSHAL exception with standard minor code j+1 should be thrown when an incomplete final fragment was received. One situation in which this can occur is in GIOP 1.2 if a server encounters an error after having already sent fragments of the reply to the client. Date: Wed, 06 Jun 2001 14:01:14 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Everett Anderson Cc: interop@emerald.omg.org Subject: Re: Vote 2 for Interop RTF (new proposal for Issue 4289 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: [_Od9-lNd9,8gd9_:n!! Everett Anderson wrote: > > Hi, > > > I provides no guidance in the revised specification on how and when this > > new minor code should be used. There is a bit of discussion in the issue > > itself, but no proposed additional text reflecting any of that for > > inclusion in the standard. It is too much to expect people to have to go > > hunting through the issue resolutions to figure out what was in the back > > of peoples minds when they added a particular minor code. > > The description of meaning of the minor code is general, but the use is > specific and clear -- whenever one unmarshals past the end of the stream > (received the final fragment, but were expecting more data), throw a MARSHAL > exception with the error code. > > It would be a little bit better if we could note that ONE of the possible > causes for this situation is that the server received an exception after > already sending some of the response fragments back to the client. > > Since it can occur due to several conditions, we can't specify one exact > situation client-server scenario in the spec. For instance, if custom > marshaling code tries to read too much, we would expect the same minor code, > but it wouldn't have been caused by the server getting an exception. All that is fine, but notwithstanding all that, the general usage of this minor code needs to be documented in Chapter 15 at some appropriate place. It is unreasonable to expect people to have to read through the descriptions associated with minor codes in Chapter 4 to decide for themselves when it is appropriate to use it. I'd suggest that a paragraph be added somewhere appropriate in Chapter 15 basically saying in essence what you have articulated in the paragraphs above. Jishnu. Date: Wed, 06 Jun 2001 14:06:00 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Everett Anderson Cc: terutt@lucent.com, interop@omg.org Subject: Re: Vote 2 for Interop RTF (new proposal for Issue 4289 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: X,F!!>B>e9MACe9TJ\!! Everett Anderson wrote: > > Hi, > > Would the following slight amendment to the resolution for 4289 be > sufficient? > > > > Revised Text: Add the following new minor code to the table for system > > > exceptions: > > > > > > System Exception Minor Code Description > > > MARSHALL j+1 An incomplete final > > > fragment was received for a fragmented response > > and in CORBA formal 00-11-03 15.4.9 (Fragment Message) after the > CancelRequest note but before the "A primitive data type of 8 bytes or > smaller should never be broken across two > fragments." paragraph add > > A MARSHAL exception with standard minor code j+1 should be thrown when an > incomplete final fragment was received. One situation in which this can > occur is in GIOP 1.2 if a server encounters an error after having already > sent fragments of the reply to the client. Yes, I like that. Thanks, Jishnu. Date: Wed, 06 Jun 2001 17:59:42 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Everett Anderson CC: jishnu_mukerji@hp.com, interop@omg.org Subject: Re: Vote 2 for Interop RTF (new proposal for Issue 4289 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: B?g!!C`~e9#31e9J>p!! Status: RO This sounds editorial to me. It does not change the implementation of the proposed resolution. If anyone objects to this editorial addition, let us know Everett Anderson wrote: > > Hi, > > Would the following slight amendment to the resolution for 4289 be > sufficient? > > > > Revised Text: Add the following new minor code to the table for system > > > exceptions: > > > > > > System Exception Minor Code Description > > > MARSHALL j+1 An incomplete final > > > fragment was received for a fragmented response > > and in CORBA formal 00-11-03 15.4.9 (Fragment Message) after the > CancelRequest note but before the "A primitive data type of 8 bytes or > smaller should never be broken across two > fragments." paragraph add > > A MARSHAL exception with standard minor code j+1 should be thrown when an > incomplete final fragment was received. One situation in which this can > occur is in GIOP 1.2 if a server encounters an error after having already > sent fragments of the reply to the client. -- ---------- Tom Rutt Tel: +1 732 949 7862 Global Strategic Standards Fax: +1 732 949 1192 Lucent Technologies terutt@lucent.com X-Authentication-Warning: emerald.omg.org: hobbit.omg.org [192.67.184.3] didn't use HELO protocol Received: from unknown (63.78.120.98) by hobbit.omg.org asmtp(1.0) id 9600; Thu, 07 Jun 2001 22:34:54 -0400 (EDT) Received: from theep.net (IDENT:rk@theep.theep.net [63.78.120.98]) by theep.theep.net (8.9.3/8.9.3) with ESMTP id WAA18970 for ; Thu, 7 Jun 2001 22:29:59 -0400 Sender: rk@theep.net Message-ID: <3B2038A7.BBE7935F@theep.net> Date: Thu, 07 Jun 2001 22:29:59 -0400 From: Robert Kukura X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.17-14 i586) X-Accept-Language: en MIME-Version: 1.0 To: interop@omg.org Subject: [Fwd: interop vote question] Content-Type: multipart/mixed; boundary="------------0914438F9A16B081FD4CDB32" X-UIDL: K7ad9\YNe9N/Ie9R,,!! I'm having trouble getting mail to OMG from IONA, so I'm trying from a different account. -BobReturn-Path: Received: from karloff.boston.amer.iona.com (boston.amer.iona.com [63.65.132.35] (may be forged)) by theep.theep.net (8.9.3/8.9.3) with ESMTP id WAA18962 for ; Thu, 7 Jun 2001 22:26:04 -0400 Received: from iona.com ([10.64.1.20]) by karloff.boston.amer.iona.com (8.9.3/iona-1.02-sjamison) with ESMTP id WAA12800 for ; Thu, 7 Jun 2001 22:25:28 -0400 (EDT) Message-ID: <3B20376F.D93A359A@iona.com> Date: Thu, 07 Jun 2001 22:24:47 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: rk@theep.net Subject: interop vote question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I was about ready to vote, and noticed a couple of possible problems with the resolutions for 4273 (vote 1) and 4289 (vote 2): 1) 4273 specificies a single minor code to be used when the length expected for the the recieved message disagrees with the header byte count. Orbix 2000 uses two different proprietary minor codes for this - one for extra data on the wire and one for not enough data on the wire. I think its useful to distinguish these cases, but the proposal makes this non-conformant. 2) 4289 specifies a different minor code indicating an incomplete final fragment. How is this different than the "not enough data on the wire" situation in the resolution to 4273? Is the intent to distinguish between not enough data in a fragmentmented message and not enough data in a non-fragmented message? I really don't see the point in this. If so, it still seems inconsistent with the resolution to 4273 since 4273 doesn't say it is specific to non-fragmented messages. Am I missing something here? When I figure out our position on 4299 and vote, I'm intending to vote NO on both 4273 and 4289 unless someone clears this up, and I'd suggest others do the same if you think the these are real problems with the resolutions. In case it wasn't clear, I'd strongly prefer that we didn't distinguish between fragmented and non-fragmented messages, and did distinguish between too much and too little data. Thanks, -Bob Date: Fri, 08 Jun 2001 09:53:03 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Robert Kukura CC: interop@omg.org Subject: Re: [Fwd: interop vote question] References: <3B2038A7.BBE7935F@theep.net> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: <)Pe9l/3e9R]4!!ajH!! Bob, I was confused at first but this is my understanding. Kukura wrote > > 2) 4289 specifies a different minor code indicating an incomplete final > fragment. How is this different than the "not enough data on the wire" > situation in the resolution to 4273? Is the intent to distinguish > between not enough data in a fragmentmented message and not enough data > in a non-fragmented message? I really don't see the point in this. If > so, it still seems inconsistent with the resolution to 4273 since 4273 > doesn't say it is specific to non-fragmented messages. The difference is the fragment is a message with its own message length in the header. The first minor code is for this situation. I agree that two codes, one for less than, the other for greater than is a good addition, and you should perhaps vote no with a strong objection and your proposal, which I would send out for a new vote if you did so. I do not think it is editorial, so I would want a new vote. The second situation is that the message in the final fragment agrees with its size in the header, but the overall content of the concatenated set of fragments leaves the marshalling engine for the operation in a starved condition after the last fragment is received (i.e., incomplete final fragment) -- ---------- Tom Rutt Tel: +1 732 949 7862 Global Strategic Standards Fax: +1 732 949 1192 Lucent Technologies terutt@lucent.com Sender: jon@corvette.floorboard.com Message-ID: <3B20ED11.487FDBDC@floorboard.com> Date: Fri, 08 Jun 2001 08:19:45 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: terutt@lucent.com CC: Robert Kukura , interop@omg.org Subject: Re: [Fwd: interop vote question] References: <3B2038A7.BBE7935F@theep.net> <3B20D8BF.BD482A0@lucent.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: $Z&!!Tped9"&N!!gV%!! Tom Rutt wrote: > > 2) 4289 specifies a different minor code indicating an incomplete final > > fragment. How is this different than the "not enough data on the wire" > > situation in the resolution to 4273? Is the intent to distinguish > > between not enough data in a fragmentmented message and not enough data > > in a non-fragmented message? I really don't see the point in this. If > > so, it still seems inconsistent with the resolution to 4273 since 4273 > > doesn't say it is specific to non-fragmented messages. > The difference is the fragment is a message with its own message > length in the header. The first minor code is for this situation. > > I agree that two codes, one for less than, the other for greater than is > a good addition, and you should perhaps vote no with a strong objection and > your proposal, which I would send out for a new vote if you did so. I do not > think it is editorial, so I would want a new vote. Perhaps so, but let's make sure we get it right this time. There are only two ways to get less data than indicated in the header, since IIOP runs over TCP, which is a stream protocol. 1. The connection closes prematurely. In this case, you've got a COMM_FAILURE, not a MARSHAL exception. 2. In GIOP 1.1, a new message starts without the final fragment of a previously fragmented message. This can be a MARSSHAL exception, but it would be a good idea to assign a specific minor code describing this case. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Fri, 08 Jun 2001 12:15:57 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: terutt@lucent.com, interop@omg.org Subject: Re: Vote 2 for Interop RTF (new proposal for Issue 4289 References: <3B1C0949.350A7081@lucent.com> <3B1D18CC.3F64710B@hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: %8-!!R8He9/f6!!B)A!! Jishnu Mukerji wrote: > > HP votes NO on this resolution 4289. > > I provides no guidance in the revised specification on how and when this > new minor code should be used. There is a bit of discussion in the issue > itself, but no proposed additional text reflecting any of that for > inclusion in the standard. It is too much to expect people to have to go > hunting through the issue resolutions to figure out what was in the back > of peoples minds when they added a particular minor code. Well, judging from Bob's message it looks like the problems with this one is worse than I had originally thought. So let me reconfirm my NO vote on this one. I would really like to see a clear specification of the conditions under which this minor code would be used stated somewhere in Chapter 15. I thought the proposed additions came close, but now I am less convinced of that, since there appears to be considerable disagreement on what the circumstances are under which this minor code should be returned. Regards, Jishnu. Date: Fri, 08 Jun 2001 14:55:58 -0700 From: Vijaykumar Natarajan Subject: Re: Interop Final Wordsmith before Vote 3 To: terutt@lucent.com Cc: interop@omg.org Message-id: <3B2149EE.B41F97CE@inprise.com> Organization: Borland Software Corporation MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: <3B21422F.55EBC160@lucent.com> Content-Type: multipart/mixed; boundary="Boundary_(ID_g+A51ScbijHxAaDOF2DVtw)" X-UIDL: :FM!!&8d!!aGY!!SgB!! Status: RO All, Comments on this: > ---------------------------------------------------------------------- > > Issue 4273: GIOP is silent about extra data in the Request or Reply > body (interop) As I mentioned earlier, detecting extra data at the end of a request or reply in the Java portable stub model is not possible w/o some hackery and even so, cannot be done before actually dispatching the request to the servant. ORBs should not be required to detect the overflow condition. > ---------------------------------------------------------------------- > > Issue 4289: GIOP issue : fragmented replies with exceptions (interop) > Resolution: To close without revision First, the above should say close w/ revision Second, the resolution still does not say what the server should do when it encounters a problem. I would propose inserting a third paragraph to section 15.4.9 before the other two. When a server detects an error after having marshaled earlier fragments for a reply, it will send an empty fragment with the fragments to follow bit turned off. Thanks, vijay [] vnatarajan4.vcf Date: Thu, 1 Nov 2001 17:08:49 +1000 (EST) From: Michi Henning To: Interoperability RTF Subject: Re: Interop vote 1 In-Reply-To: Message-ID: Organization: IONA Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: olc!!K]B!!VEn!!5QSd9 On Fri, 26 Oct 2001, Michi Henning wrote: > attached are a few issues to vote on. Votes are due by Friday, 2 November. > Voting members of the RTF are listed at > > http://www.omg.org/techprocess/meetings/schedule/Interop_December_2000_RTF.html IONA votes no on 4334, and yes on all other issues. For 4273/4289, here is a friendly amendment: Change the proposed text: The count includes any alignment gaps and must match the size of the actual request parameters (plus any final padding bytes that may follow the parameters to have a fragment message terminate on an 8-byte boundary). To read: The count includes any alignment gaps and must match the size of the actual request parameters (plus any final padding bytes that may follow the parameters to have a non-final fragment message ^^^^^^^^^ terminate on an 8-byte boundary). This makes it more explicit that the 8-byte alignment requirement does not apply to the terminating fragment of a message. Cheers, Michi. -- Michi Henning +61 7 3324 9633 Chief CORBA Scientist +61 4 1118 2700 (mobile) IONA Technologies +61 7 3324 9799 (fax) Total Business Integration http://www.ooc.com.au/staff/michi From: "Everett Anderson" To: "Michi Henning" , "Interoperability RTF" Subject: RE: Interop vote 1 Date: Wed, 31 Oct 2001 23:46:02 -0800 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Content-Type: text/plain; charset="us-ascii" X-UIDL: Kc*!!BiO!!O@Ne9O9bd9 Hi, > IONA votes no on 4334, and yes on all other issues. Sun also votes no on 4334 and yes on all other issues, with the following comment: For 4289, I'd like to add to the GIOP 1.3 wish list to find a way to make it possible for a server to convey error/exception info back to the client when the server has already sent a few fragments of the reply. - Everett