[omniORB] Strange effects with oneway operations

[Wernke zur Borg]

Thank you very much for your investigation and explanation, Duncan.

Yes, I am sure there was no further input message nor upcall later on.
Instead, there was some time of inactivity (about 10-15 seconds) until the
application ran into a timeout condition due to the missing upcall and
aborted the session on application level.

As I wrote, the client side was still running 4.0.2 at the time of the
traces. I have upgraded to 4.0.6.develop in the meantime, and no more errors
were observed up to now.

Is it imaginable that due to a bug in 4.0.2 the rest of the message was not
sent at all?

Anyway I think I will not further investigate the problem if it turns out
that 4.0.6 solves the issue. 

Another question while we are at it. Is there a guarantee that no exceptions
occur on oneway operations? In other words, can I remove the try...catch
around those calls or is it still possible that local error conditions are
raised as exceptions?

Regards, Wernke
---
Wernke zur Borg
VEGA Informations-Technologien GmbH
Robert-Bosch-Str. 7
64293 Darmstadt / Germany
Tel: +49-(0)6151-8257-128



> -----Original Message-----
> From: Duncan Grisby [mailto:duncan at grisby.org] 
> Sent: 10 October 2005 20:11
> To: Wernke zur Borg
> Cc: omniORB-list at omniorb-support.com
> Subject: Re: [omniORB] Strange effects with oneway operations
> 
> 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 --
>