Issue 5880: Clarification on multi-threaded codeset negotiation (corba-rtf) Source: Oracle (Dr. Andrew Piper, andyp(at)bea.com) Nature: Uncategorized Issue Severity: Summary: We recently ran into a problem with a foreign Vendor's ORB and it appears the spec is unclear on this issue. The problem occurs when a multi-threaded client is connecting to a server. The spec says (13.10.2.6): "Codeset negotiation is not performed on a per-request basis, but only when a client initially connects to a server. All text data communicated on a connection are encoded as defined by the TCSs selected when the connection is established." but is silent on what is supposed to happen if the client has multiple threads all trying to connect at the same time. The issue is that priority inversion can occur - either because the client sends out a request without the negotiated codeset before the one with the negotiated codeset, or because the server processes the request without the negotiated codeset before the one with the negotiated codeset (even if the latter was sent first). The problem we encountered was the latter. There are two possible approaches to solving this: a) Require the server to serialize connection establishment requests until the codeset (and other connection information) is negotiated. This requires that the client impose appropriate ordering on connection requests. b) Require that the client keep sending codeset (and other connection information) until it is sure that the server has received the information (by getting a reply back). This works ok unless you are exclusively using oneways. In this instance you have to keep sending codeset information forever (somewhat costly, and very costly for codebase information). CSIv2 (26.2.2.3) explicitly calls out (b) but I prefer (a). Do we have any guidance on what is supposed to happen? Resolution: Revised Text: Actions taken: March 11, 2003: received issue April 11, 2012: Deferred Discussion: End of Annotations:===== X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 11 Mar 2003 09:41:54 -0800 To: corba-rtf@omg.org From: Andy Piper Subject: Clarification on multi-threaded codeset negotiation Cc: issues@omg.org, andyp@bea.com We recently ran into a problem with a foreign Vendor's ORB and it appears the spec is unclear on this issue. The problem occurs when a multi-threaded client is connecting to a server. The spec says (13.10.2.6): "Codeset negotiation is not performed on a per-request basis, but only when a client initially connects to a server. All text data communicated on a connection are encoded as defined by the TCSs selected when the connection is established." but is silent on what is supposed to happen if the client has multiple threads all trying to connect at the same time. The issue is that priority inversion can occur - either because the client sends out a request without the negotiated codeset before the one with the negotiated codeset, or because the server processes the request without the negotiated codeset before the one with the negotiated codeset (even if the latter was sent first). The problem we encountered was the latter. There are two possible approaches to solving this: a) Require the server to serialize connection establishment requests until the codeset (and other connection information) is negotiated. This requires that the client impose appropriate ordering on connection requests. b) Require that the client keep sending codeset (and other connection information) until it is sure that the server has received the information (by getting a reply back). This works ok unless you are exclusively using oneways. In this instance you have to keep sending codeset information forever (somewhat costly, and very costly for codebase information). CSIv2 (26.2.2.3) explicitly calls out (b) but I prefer (a). Do we have any guidance on what is supposed to happen? andy Date: Tue, 11 Mar 2003 13:13:55 -0500 From: Tom Rutt Reply-To: tom@coastin.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: Andy Piper CC: corba-rtf@omg.org, issues@omg.org Subject: Re: Clarification on multi-threaded codeset negotiation Issue 3318 (which was closed with resolution) was on this topic. I do not have the resolution because of the server problem, but check it out before you file a new issue. Tom Rutt Andy Piper wrote: We recently ran into a problem with a foreign Vendor's ORB and it appears the spec is unclear on this issue. The problem occurs when a multi-threaded client is connecting to a server. The spec says (13.10.2.6): "Codeset negotiation is not performed on a per-request basis, but only when a client initially connects to a server. All text data communicated on a connection are encoded as defined by the TCSs selected when the connection is established." but is silent on what is supposed to happen if the client has multiple threads all trying to connect at the same time. The issue is that priority inversion can occur - either because the client sends out a request without the negotiated codeset before the one with the negotiated codeset, or because the server processes the request without the negotiated codeset before the one with the negotiated codeset (even if the latter was sent first). The problem we encountered was the latter. There are two possible approaches to solving this: a) Require the server to serialize connection establishment requests until the codeset (and other connection information) is negotiated. This requires that the client impose appropriate ordering on connection requests. b) Require that the client keep sending codeset (and other connection information) until it is sure that the server has received the information (by getting a reply back). This works ok unless you are exclusively using oneways. In this instance you have to keep sending codeset information forever (somewhat costly, and very costly for codebase information). CSIv2 (26.2.2.3) explicitly calls out (b) but I prefer (a). Do we have any guidance on what is supposed to happen? andy -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 X-Sender: juergen@emerald.omg.org X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 11 Mar 2003 13:35:12 -0500 To: tom@coastin.com, Andy Piper From: Juergen Boldt Subject: Re: Clarification on multi-threaded codeset negotiation Cc: corba-rtf@omg.org, issues@omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id h2BIXt417337 All, the resolution to issue 3318 attached -Juergen 1. In orbrev/02-02-01 in section 13.10.2.6 "Code Set Negotiation" insert the following as the third from last paragraph of the section, immediately preceding the para that begins: "To guarantee "out of the box" interoperability......": If the client (or the server if Bi-Directional GIOP is in use) sends multiple codeset service contexts on the same connection, with different paramter values, then the behavior is undefined. The reciever of a codeset service context with different values from those recieved on the same connection and processed previously may return a MARSHAL system exception with the standard minor code j. 2. Add the following minor code to the MARSHAL system exception. minor code: j description: codeset service contexts with different values recieved on the same connection. At 01:13 PM 3/11/2003 -0500, Tom Rutt wrote: Issue 3318 (which was closed with resolution) was on this topic. I do not have the resolution because of the server problem, but check it out before you file a new issue. Tom Rutt Andy Piper wrote: We recently ran into a problem with a foreign Vendor's ORB and it appears the spec is unclear on this issue. The problem occurs when a multi-threaded client is connecting to a server. The spec says (13.10.2.6): "Codeset negotiation is not performed on a per-request basis, but only when a client initially connects to a server. All text data communicated on a connection are encoded as defined by the TCSs selected when the connection is established." but is silent on what is supposed to happen if the client has multiple threads all trying to connect at the same time. The issue is that priority inversion can occur - either because the client sends out a request without the negotiated codeset before the one with the negotiated codeset, or because the server processes the request without the negotiated codeset before the one with the negotiated codeset (even if the latter was sent first). The problem we encountered was the latter. There are two possible approaches to solving this: a) Require the server to serialize connection establishment requests until the codeset (and other connection information) is negotiated. This requires that the client impose appropriate ordering on connection requests. b) Require that the client keep sending codeset (and other connection information) until it is sure that the server has received the information (by getting a reply back). This works ok unless you are exclusively using oneways. In this instance you have to keep sending codeset information forever (somewhat costly, and very costly for codebase information). CSIv2 (26.2.2.3) explicitly calls out (b) but I prefer (a). Do we have any guidance on what is supposed to happen? andy -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 ================================= J|rgen Boldt Director, Member Services Object Management Group 250 First Avenue, Suite 100 Needham, MA 02494 Tel. +1 781 444 0404 ext. 132 Fax: +1 781 444 0320 email: juergen@omg.org www www.omg.org ================================ X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 11 Mar 2003 16:38:16 -0800 To: Juergen Boldt From: Andy Piper Subject: Re: Clarification on multi-threaded codeset negotiation Cc: tom@coastin.com, corba-rtf@omg.org, issues@omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id h2C0fQ421505 This is a different issue IMO andy At 01:35 PM 3/11/2003 -0500, Juergen Boldt wrote: All, the resolution to issue 3318 attached -Juergen 1. In orbrev/02-02-01 in section 13.10.2.6 "Code Set Negotiation" insert the following as the third from last paragraph of the section, immediately preceding the para that begins: "To guarantee "out of the box" interoperability......": If the client (or the server if Bi-Directional GIOP is in use) sends multiple codeset service contexts on the same connection, with different paramter values, then the behavior is undefined. The reciever of a codeset service context with different values from those recieved on the same connection and processed previously may return a MARSHAL system exception with the standard minor code j. 2. Add the following minor code to the MARSHAL system exception. minor code: j description: codeset service contexts with different values recieved on the same connection. At 01:13 PM 3/11/2003 -0500, Tom Rutt wrote: Issue 3318 (which was closed with resolution) was on this topic. I do not have the resolution because of the server problem, but check it out before you file a new issue. Tom Rutt Andy Piper wrote: We recently ran into a problem with a foreign Vendor's ORB and it appears the spec is unclear on this issue. The problem occurs when a multi-threaded client is connecting to a server. The spec says (13.10.2.6): "Codeset negotiation is not performed on a per-request basis, but only when a client initially connects to a server. All text data communicated on a connection are encoded as defined by the TCSs selected when the connection is established." but is silent on what is supposed to happen if the client has multiple threads all trying to connect at the same time. The issue is that priority inversion can occur - either because the client sends out a request without the negotiated codeset before the one with the negotiated codeset, or because the server processes the request without the negotiated codeset before the one with the negotiated codeset (even if the latter was sent first). The problem we encountered was the latter. There are two possible approaches to solving this: a) Require the server to serialize connection establishment requests until the codeset (and other connection information) is negotiated. This requires that the client impose appropriate ordering on connection requests. b) Require that the client keep sending codeset (and other connection information) until it is sure that the server has received the information (by getting a reply back). This works ok unless you are exclusively using oneways. In this instance you have to keep sending codeset information forever (somewhat costly, and very costly for codebase information). CSIv2 (26.2.2.3) explicitly calls out (b) but I prefer (a). Do we have any guidance on what is supposed to happen? andy -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 ================================= J|rgen Boldt Director, Member Services Object Management Group 250 First Avenue, Suite 100 Needham, MA 02494 Tel. +1 781 444 0404 ext. 132 Fax: +1 781 444 0320 email: juergen@omg.org www www.omg.org ================================ Date: Wed, 12 Mar 2003 09:37:56 -0500 From: Bob Kukura User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en To: Andy Piper CC: Juergen Boldt , tom@coastin.com, corba-rtf@omg.org Subject: Re: Clarification on multi-threaded codeset negotiation X-OriginalArrivalTime: 12 Mar 2003 14:38:36.0539 (UTC) FILETIME=[10973CB0:01C2E8A5] Hi Andy, I think the issues are closely related, and that the decision made in 3318 was the result of consideration of the issue you have raised. The scenario described in the quoted text from 3318 occurs because clients can issue multiple requests before there is any guarantee that a request sent over the connection has been processed in the server, and that the order in which the server processes requests' service contexts is not guaranteed (consider interleaved requests with fragmentation boundaries in the middle of the service context list). I clearly recall this being discussed, and remember describing how ORBs I am familiar with send the codeset service context with all requests until a reply has been received. I don't think it would be possible to retroactively add a requirement that clients not send concurrent requests until a reply has been received. Even if this was in the context of a new GIOP version, I do not think this would be appropriate because there is no bound on how long the initial request sent on a connection might take to complete. My understanding was that your solution (b) was already implied, if not explicitly described, by the GIOP specification. -Bob Andy Piper wrote: This is a different issue IMO andy At 01:35 PM 3/11/2003 -0500, Juergen Boldt wrote: All, the resolution to issue 3318 attached -Juergen 1. In orbrev/02-02-01 in section 13.10.2.6 "Code Set Negotiation" insert the following as the third from last paragraph of the section, immediately preceding the para that begins: "To guarantee "out of the box" interoperability......": If the client (or the server if Bi-Directional GIOP is in use) sends multiple codeset service contexts on the same connection, with different paramter values, then the behavior is undefined. The reciever of a codeset service context with different values from those recieved on the same connection and processed previously may return a MARSHAL system exception with the standard minor code j. 2. Add the following minor code to the MARSHAL system exception. minor code: j description: codeset service contexts with different values recieved on the same connection. At 01:13 PM 3/11/2003 -0500, Tom Rutt wrote: Issue 3318 (which was closed with resolution) was on this topic. I do not have the resolution because of the server problem, but check it out before you file a new issue. Tom Rutt Andy Piper wrote: We recently ran into a problem with a foreign Vendor's ORB and it appears the spec is unclear on this issue. The problem occurs when a multi-threaded client is connecting to a server. The spec says (13.10.2.6): "Codeset negotiation is not performed on a per-request basis, but only when a client initially connects to a server. All text data communicated on a connection are encoded as defined by the TCSs selected when the connection is established." but is silent on what is supposed to happen if the client has multiple threads all trying to connect at the same time. The issue is that priority inversion can occur - either because the client sends out a request without the negotiated codeset before the one with the negotiated codeset, or because the server processes the request without the negotiated codeset before the one with the negotiated codeset (even if the latter was sent first). The problem we encountered was the latter. There are two possible approaches to solving this: a) Require the server to serialize connection establishment requests until the codeset (and other connection information) is negotiated. This requires that the client impose appropriate ordering on connection requests. b) Require that the client keep sending codeset (and other connection information) until it is sure that the server has received the information (by getting a reply back). This works ok unless you are exclusively using oneways. In this instance you have to keep sending codeset information forever (somewhat costly, and very costly for codebase information). CSIv2 (26.2.2.3) explicitly calls out (b) but I prefer (a). Do we have any guidance on what is supposed to happen? andy -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 ================================= J|rgen Boldt Director, Member Services Object Management Group 250 First Avenue, Suite 100 Needham, MA 02494 Tel. +1 781 444 0404 ext. 132 Fax: +1 781 444 0320 email: juergen@omg.org www www.omg.org ================================ Date: Wed, 12 Mar 2003 10:49:37 -0500 From: Tom Rutt Reply-To: tom@coastin.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: Andy Piper CC: Juergen Boldt , corba-rtf@omg.org, issues@omg.org Subject: Re: Clarification on multi-threaded codeset negotiation ON the receieving end of the connection, there is no way to distinguish your case from the case in issue 3318. Because different orbs have all done different things when multiple codeset contexts are sent, and the spec implies you should only send it once at the beginning, we came up with the solution in 3318. tom Rutt Andy Piper wrote: This is a different issue IMO andy At 01:35 PM 3/11/2003 -0500, Juergen Boldt wrote: All, the resolution to issue 3318 attached -Juergen 1. In orbrev/02-02-01 in section 13.10.2.6 "Code Set Negotiation" insert the following as the third from last paragraph of the section, immediately preceding the para that begins: "To guarantee "out of the box" interoperability......": If the client (or the server if Bi-Directional GIOP is in use) sends multiple codeset service contexts on the same connection, with different paramter values, then the behavior is undefined. The reciever of a codeset service context with different values from those recieved on the same connection and processed previously may return a MARSHAL system exception with the standard minor code j. 2. Add the following minor code to the MARSHAL system exception. minor code: j description: codeset service contexts with different values recieved on the same connection. At 01:13 PM 3/11/2003 -0500, Tom Rutt wrote: Issue 3318 (which was closed with resolution) was on this topic. I do not have the resolution because of the server problem, but check it out before you file a new issue. Tom Rutt Andy Piper wrote: We recently ran into a problem with a foreign Vendor's ORB and it appears the spec is unclear on this issue. The problem occurs when a multi-threaded client is connecting to a server. The spec says (13.10.2.6): "Codeset negotiation is not performed on a per-request basis, but only when a client initially connects to a server. All text data communicated on a connection are encoded as defined by the TCSs selected when the connection is established." but is silent on what is supposed to happen if the client has multiple threads all trying to connect at the same time. The issue is that priority inversion can occur - either because the client sends out a request without the negotiated codeset before the one with the negotiated codeset, or because the server processes the request without the negotiated codeset before the one with the negotiated codeset (even if the latter was sent first). The problem we encountered was the latter. There are two possible approaches to solving this: a) Require the server to serialize connection establishment requests until the codeset (and other connection information) is negotiated. This requires that the client impose appropriate ordering on connection requests. b) Require that the client keep sending codeset (and other connection information) until it is sure that the server has received the information (by getting a reply back). This works ok unless you are exclusively using oneways. In this instance you have to keep sending codeset information forever (somewhat costly, and very costly for codebase information). CSIv2 (26.2.2.3) explicitly calls out (b) but I prefer (a). Do we have any guidance on what is supposed to happen? andy -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 ================================= J|rgen Boldt Director, Member Services Object Management Group 250 First Avenue, Suite 100 Needham, MA 02494 Tel. +1 781 444 0404 ext. 132 Fax: +1 781 444 0320 email: juergen@omg.org www www.omg.org ================================ -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 12 Mar 2003 09:45:13 -0800 To: tom@coastin.com From: Andy Piper Subject: Re: Clarification on multi-threaded codeset negotiation Cc: Juergen Boldt , corba-rtf@omg.org, issues@omg.org At 10:49 AM 3/12/2003 -0500, Tom Rutt wrote: ON the receieving end of the connection, there is no way to distinguish your case from the case in issue 3318. Because different orbs have all done different things when multiple codeset contexts are sent, and the spec implies you should only send it once at the beginning, we came up with the solution in 3318. Ok but the resolution seems to exclude my case, since the issue I am seeing is where some requests have _no_ service context rather than _different_ parameter values. So it seems to me that the resolution is unclear on this point. andy X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 12 Mar 2003 09:48:37 -0800 To: Bob Kukura From: Andy Piper Subject: Re: Clarification on multi-threaded codeset negotiation Cc: Juergen Boldt , tom@coastin.com, corba-rtf@omg.org Hi Bob, At 09:37 AM 3/12/2003 -0500, Bob Kukura wrote: until a reply has been received. I don't think it would be possible to retroactively add a requirement that clients not send concurrent requests until a reply has been received. Even if this was in the context of a new GIOP version, I do not think this would be appropriate because there is no bound on how long the initial request sent on a connection might take to complete. My understanding Ok, this seems reasonable. was that your solution (b) was already implied, if not explicitly described, by the GIOP specification. Its a subtle implication if it is actually there, I think it should be explicitly called out as it is in CSIv2. Note that codesets are just one example of things that may run into this problem. Maybe there should be a more general section about connection establishment and multi-threaded clients/servers. andy Date: Wed, 12 Mar 2003 13:28:42 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: Andy Piper Cc: Bob Kukura , Juergen Boldt , tom@coastin.com, corba-rtf@omg.org Subject: Re: Clarification on multi-threaded codeset negotiation Andy Piper wrote: Hi Bob, At 09:37 AM 3/12/2003 -0500, Bob Kukura wrote: until a reply has been received. I don't think it would be possible to retroactively add a requirement that clients not send concurrent requests until a reply has been received. Even if this was in the context of a new GIOP version, I do not think this would be appropriate because there is no bound on how long the initial request sent on a connection might take to complete. My understanding Ok, this seems reasonable. was that your solution (b) was already implied, if not explicitly described, by the GIOP specification. Its a subtle implication if it is actually there, I think it should be explicitly called out as it is in CSIv2. A one sentence clarification of this seem reasonable. Note that codesets are just one example of things that may run into this problem. Maybe there should be a more general section about connection establishment and multi-threaded clients/servers. Perhaps the principle established for codeset in the resolution for 3318, together with Andy's (b) is the thing that should be made applicable generally for all service contexts, and be done with it. i don't think getting your case (a) established in the specification has a prayer at present. Jishnu. Date: Wed, 12 Mar 2003 19:30:37 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Jishnu Mukerji CC: Andy Piper , Bob Kukura , Juergen Boldt , tom@coastin.com, corba-rtf@omg.org Subject: Re: Clarification on multi-threaded codeset negotiation Jishnu, This works for service contexts that are sent on requests (except one-way requests). It doesn't work for service contexts that can be sent on replies, such as SendingContextRunTime. So it is not a general solution for this problem. For a general solution, a new GIOP mechanism for session establishment is needed. Simon Jishnu Mukerji wrote: > > Andy Piper wrote: > > Hi Bob, > > > > At 09:37 AM 3/12/2003 -0500, Bob Kukura wrote: > > > >> until a reply has been received. I don't think it would be possible to > >> retroactively add a requirement that clients not send concurrent > >> requests until a reply has been received. Even if this was in the > >> context of a new GIOP version, I do not think this would be > >> appropriate because there is no bound on how long the initial request > >> sent on a connection might take to complete. My understanding > > > > > > Ok, this seems reasonable. > > > >> was that your solution (b) was already implied, if not explicitly > >> described, by the GIOP specification. > > > > > > Its a subtle implication if it is actually there, I think it should be > > explicitly called out as it is in CSIv2. > > A one sentence clarification of this seem reasonable. > > > Note that codesets are just one > > example of things that may run into this problem. Maybe there should be > > a more general section about connection establishment and multi-threaded > > clients/servers. > > Perhaps the principle established for codeset in the resolution for 3318, together with > Andy's (b) is the thing that should be made applicable generally for all service contexts, > and be done with it. > > i don't think getting your case (a) established in the specification has a prayer at present. > > Jishnu. -- Simon C Nash, Chief Technical Officer, IBM Java Technology Hursley Park, Winchester, UK nash@hursley.ibm.com Tel. +44-1962-815156 Fax +44-1962-818999 Date: Wed, 12 Mar 2003 14:42:36 -0500 From: Tom Rutt Reply-To: tom@coastin.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: Simon Nash CC: Jishnu Mukerji , Andy Piper , Bob Kukura , Juergen Boldt , corba-rtf@omg.org Subject: Re: Clarification on multi-threaded codeset negotiation Did not the new firewall submission add a new giop message for sending context? Tom Rutt Simon Nash wrote: Jishnu, This works for service contexts that are sent on requests (except one-way requests). It doesn't work for service contexts that can be sent on replies, such as SendingContextRunTime. So it is not a general solution for this problem. For a general solution, a new GIOP mechanism for session establishment is needed. Simon Jishnu Mukerji wrote: Andy Piper wrote: Hi Bob, At 09:37 AM 3/12/2003 -0500, Bob Kukura wrote: until a reply has been received. I don't think it would be possible to retroactively add a requirement that clients not send concurrent requests until a reply has been received. Even if this was in the context of a new GIOP version, I do not think this would be appropriate because there is no bound on how long the initial request sent on a connection might take to complete. My understanding Ok, this seems reasonable. was that your solution (b) was already implied, if not explicitly described, by the GIOP specification. Its a subtle implication if it is actually there, I think it should be explicitly called out as it is in CSIv2. A one sentence clarification of this seem reasonable. Note that codesets are just one example of things that may run into this problem. Maybe there should be a more general section about connection establishment and multi-threaded clients/servers. Perhaps the principle established for codeset in the resolution for 3318, together with Andy's (b) is the thing that should be made applicable generally for all service contexts, and be done with it. i don't think getting your case (a) established in the specification has a prayer at present. Jishnu. -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 Date: Wed, 12 Mar 2003 12:41:47 -0800 From: Jonathan Biggar User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202 X-Accept-Language: en-us, en Cc: corba-rtf@omg.org Subject: Re: Clarification on multi-threaded codeset negotiation Simon Nash wrote: Jishnu, This works for service contexts that are sent on requests (except one-way requests). It doesn't work for service contexts that can be sent on replies, such as SendingContextRunTime. So it is not a general solution for this problem. For a general solution, a new GIOP mechanism for session establishment is needed. The Adopted Firewall specification's NegotiateSession GIOP message can be coopted for this. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 12 Mar 2003 13:16:30 -0800 From: Jonathan Biggar User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202 X-Accept-Language: en-us, en To: core-rtf@omg.org Subject: Re: Clarification on multi-threaded codeset negotiation Jishnu Mukerji wrote: Not all service contexts, of course, but only those whose effects have connection-wide scope. It would also be a very good idea if the table of service contexts explicitly designated which ones have connection-wide effects and which ones only affect the request they inhabit. You're right. Only connection-wide scope service contexts. Just as a homework exercise, would you like to take a first crack at classifying the standard service contexts into those that are connection-wide scope and those that are not. The list of standard service contexts appear in Appendix something or the other in the the Formal CORBA 3.0. Do I get extra credit? Here's the list of connection-wide scoped SCs: CodeSets BI_DIR_IIOP SendingContextRunTime SecurityAttributeService Each of these has some unique semantics, though: CodeSets can only be sent by the original client side and affects data transmission/interpretation in both directions, and can never change from its initial value. BI_DIR_IIOP also can only be sent by the original client-side, but can be sent multiple times with different values, all of which are significant. SendingContextRunTime can be sent by either side (even when not BiDir) but only affects data interpretation in one direction, and can be resent with a different value that overrides the old one. SecurityAttributeService is mostly on a per/request basis, but can establish "persistent" context that affects the interpretation of later requests. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 12 Mar 2003 16:31:56 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: Jonathan Biggar Cc: core-rtf@omg.org Subject: Re: Clarification on multi-threaded codeset negotiation Jon, Thanks much Jonathan Biggar wrote: Jishnu Mukerji wrote: Not all service contexts, of course, but only those whose effects have connection-wide scope. It would also be a very good idea if the table of service contexts explicitly designated which ones have connection-wide effects and which ones only affect the request they inhabit. You're right. Only connection-wide scope service contexts. Just as a homework exercise, would you like to take a first crack at classifying the standard service contexts into those that are connection-wide scope and those that are not. The list of standard service contexts appear in Appendix something or the other in the the Formal CORBA 3.0. Do I get extra credit? Always as usual:-) Here's the list of connection-wide scoped SCs: CodeSets BI_DIR_IIOP SendingContextRunTime SecurityAttributeService Each of these has some unique semantics, though: CodeSets can only be sent by the original client side and affects data transmission/interpretation in both directions, and can never change from its initial value. BI_DIR_IIOP also can only be sent by the original client-side, but can be sent multiple times with different values, all of which are significant. SendingContextRunTime can be sent by either side (even when not BiDir) but only affects data interpretation in one direction, and can be resent with a different value that overrides the old one. SecurityAttributeService is mostly on a per/request basis, but can establish "persistent" context that affects the interpretation of later requests. The varying nature of what happens with each of these suggests that this information needs to be clearly documented in conjunction with the definition of each of these service contexts. This could be done either in Chapter 13 or in places where the service context is documented, with a reference to that place in Chapter 13 (I believe the references are already there in Chapter 13 or in Appendix where the service contexts are listed). Jishnu. Date: Wed, 12 Mar 2003 16:34:28 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: Jonathan Biggar Cc: corba-rtf@omg.org Subject: Re: Clarification on multi-threaded codeset negotiation Jonathan Biggar wrote: Simon Nash wrote: Jishnu, This works for service contexts that are sent on requests (except one-way requests). It doesn't work for service contexts that can be sent on replies, such as SendingContextRunTime. So it is not a general solution for this problem. For a general solution, a new GIOP mechanism for session establishment is needed. The Adopted Firewall specification's NegotiateSession GIOP message can be coopted for this. Of course one hopes that someone is working on completing its finalization, 'cause without that the whole thing including the NegotiationSession GIOP message is liable to turn into a pumpkin.:-( If there is significant danger of that happening maybe we should start making sure that at least the NegotiationSession GIOP message part of the adopted spec becomes finalized. Jishnu.