[omniORB] Strange effects with oneway operations

[Wernke zur Borg]

Dear list,

I am currently running a test with my application to compare normal vs.
oneway operations. In the oneway variant, I notice a strange effect when
multiple invocations are executed concurrently from multiple threads in the
client.

The scenario is as follows:

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. The bufferUpdate() call is properly dispatched to Obj1. The rest
of the data is apparently discarded, at least there is no upcall for Obj2.
The remaining 676 bytes seem to have vanished.

Note that parameter "oneCallPerConnection" is set to the default of 1, but I
guess this is of no significance for oneway operations, and the connection
can be reused at any time. 

Version info:
omniORB 4.0.2 on Solaris 8 at the client side.
omniORB 4.0.6 (latest development branch) on Solaris 8 at the server side.


I am not sure if this problem is the same as the previously reported endless
loop in OmniORB although I could imagine that it might be, although that
other case was with confirmed operations.

Here are the traces:

1. Client:

2005/10/07 0748:50 CWS_trace: resp=[50215:0:2238] gateway=37a098 in
CWS_ManagedGw::bufferUpd, thr=23
omniORB: (?) Invoke 'bufferUpdate' on remote: root<6>
omniORB: (?) sendChunk: to giop:tcp:195.74.189.18:33821 7688 bytes
omniORB: (?) 128bytes out of 7688
4749 4f50 0102 0000 0000 1dfc 0000 195a GIOP...........Z
0000 0000 0000 000e 0000 000e fe43 4623 .............CF#
2d36 0b00 0000 0000 0006 0000 0000 000d -6..............
6275 6666 6572 5570 6461 7465 0000 0000 bufferUpdate....
0000 0000 0100 0000 0000 1dbc 0000 01cb ................
0000 0730 0000 0738 0000 0740 0000 0748 ...0...8... at ...H
0000 0750 0000 0758 0000 0760 0000 0768 ...P...X...`...h
0000 0770 0000 0778 0000 0780 0000 0788 ...p...x........
2005/10/07 0748:51 CWS_trace: resp=[50215:0:2151] gateway=36bb70 in
CWS_ManagedGw::bufferUpd, thr=19
omniORB: (?) Invoke 'bufferUpdate' on remote: root<4>
omniORB: (?) sendChunk: to giop:tcp:195.74.189.18:33821 1180 bytes
omniORB: (?) 128bytes out of 1180
4749 4f50 0102 0000 0000 0490 0000 195c GIOP...........\
0000 0000 0000 000e 0000 000e fe43 4623 .............CF#
2d36 0b00 0000 0000 0004 0000 0000 000d -6..............
6275 6666 6572 5570 6461 7465 0000 0000 bufferUpdate....
0000 0000 0100 0000 0000 0450 0000 0021 ...........P...!
0000 0088 0000 0090 0000 0098 0000 00a0 ................
0000 00b0 0000 00b8 0000 00c0 0000 00c8 ................
0000 00d0 0000 00dc 0000 00e4 0000 00f0 ................

===================================================

2. Server:

omniORB: (2) Scan for idle connections (1128671330,15014763)
omniORB: (2) Scavenger reduce idle count for strand 3504f8 to 22
omniORB: (2) Scavenger reduce idle count for strand 357988 to 35
omniORB: (2) Scan for idle connections done (1128671330,15014763).
omniORB: (1) Server accepted connection from giop:tcp:195.74.176.35:36527
omniORB: (3) inputMessage: from giop:tcp:195.74.176.35:36523 8192 bytes
omniORB: (3) 128 bytes out of 8192
4749 4f50 0102 0000 0000 1dfc 0000 195a GIOP...........Z
0000 0000 0000 000e 0000 000e fe43 4623 .............CF#
2d36 0b00 0000 0000 0006 0000 0000 000d -6..............
6275 6666 6572 5570 6461 7465 0000 0000 bufferUpdate....
0000 0000 0100 0000 0000 1dbc 0000 01cb ................
0000 0730 0000 0738 0000 0740 0000 0748 ...0...8... at ...H
0000 0750 0000 0758 0000 0760 0000 0768 ...P...X...`...h
0000 0770 0000 0778 0000 0780 0000 0788 ...p...x........
omniORB: (3) Split input data into 1 messages
omniORB: (3) Dispatching remote call 'bufferUpdate' to: root<6> (active)
omniORB: (451) AsyncInvoker: thread id = 451 has started. Total threads = 4
omniORB: (451) giopWorker task execute.
omniORB: (451) Accepted connection from giop:tcp:195.74.176.35:36527 because
of this rule: "* unix,ssl,t
cp"
omniORB: (451) inputMessage: from giop:tcp:195.74.176.35:36527 38 bytes
omniORB: (451) 
4749 4f50 0102 0003 0000 001a 0000 0002 GIOP............
0000 2b2c 0000 000e fe43 4623 2d36 0b00 ..+,.....CF#-6..
0000 0000 0000                          ......

=========

Thank you for any suggestion.

---
Wernke zur Borg
VEGA Informations-Technologien
Robert-Bosch-Str. 7
64293 Darmstadt