CORBA34 — Clarification on multi-threaded codeset negotiation

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?

Deferred

This proposal was generated automatically by request of the Task Force Chair Adam Mitz.