[omniORB] Strange effects with oneway operations

[Duncan Grisby]

On Friday 7 October, "Wernke zur Borg" wrote:

[...]
> Client running in thread T1 calls oneway operation bufferUpdate() on server
> object Obj1
> Client running in thread T2 calls oneway operation bufferUpdate() on server
> object Obj2
> 
> If these two calls are executed concurrently, the resulting GIOP messages
> may get concatenated on the same TCP connection. In our case the message
> lengths are 7688 + 1180 = 8868. On the server side, one message of 8192
> (receive buffer size) is received, i.e. the TCP data do not get properly
> divided into two different messages. A trace line saying "Split input data
> into 1 messages" is printed, which I have never seen before, even with large
> messages.

That is completely normal. Both the calls have been sent down the same
TCP connection, which is fine. When the server reads from the
connection, it has no idea how big the message is going to be, so it
asks for 8192 bytes. With normal blocking two-way calls, it's usual to
get just one request less than 8192 bytes (or the first 8192 bytes of a
bigger request). Since the oneway calls have been sent very close
together, the read of 8192 bytes gets the whole of the first message and
the start of the second one. omniORB notices this, and buffers the start
of the second message. The log of "split input data" relates to this --
the "into 1 messages" means 1 extra message, so really there are two
messages.

When this situation occurs, omniORB marks the connection as having data
already available in a buffer. Depending on the configuration options,
it either waits until it's processed the first request before handling
the new one, or it dispatches a new thread to handle it. Either way, it
certainly should handle the second call, reading from the connection to
get the rest of the data if need be. In my tests, it does indeed cope
properly with multiple calls that arrive at once.

In the traces you sent, the second call isn't shown being handled by the
server, but are you sure it doesn't appear later on?  Has the
bufferUpdate call that is handled finished by the time you've chopped
the log?  If the call is handled, it will appear as another inputMessage
from giop:tcp:195.74.176.35:36523, and will start with

  4749 4f50 0102 0000 0000 0490 0000 195c GIOP...........\

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --