AW: [omniORB] WG: GIOP 1.2 protocol error in input message

[Michael Sturm]

Hi Duncan,

The new attachment now is generated with traceLevel 40 in an environment running the code downloaded from omniORB-4.0-latest.tar.gz. (Did also run a test with the additional activation of traceThreadId but this obviously caused too much overhead for my application.)

Best regards,

Michael
_____________________________________________________________________________________
Michael Sturm
JDSU, Communications Test and Measurement
Phone: +49 (0)7121 86 2131
Fax:      +49 (0)7121 86 1794
e-mail: michael.sturm at jdsu.com
www: http://www.jdsu.com
 
JDSU Deutschland GmbH, Sitz: Muehleweg 5, 72800 Eningen u. A., Germany
Registergericht Stuttgart, HRB 353758, WEEE-Reg.-Nr.: DE 53620669, Geschaeftsfuehrung: Rolf Trieflinger

-----Ursprüngliche Nachricht-----
Von: Duncan Grisby [mailto:duncan at grisby.org] 
Gesendet: Freitag, 21. Dezember 2007 12:07
An: Michael Sturm
Cc: omniorb-list at omniorb-support.com
Betreff: Re: [omniORB] WG: GIOP 1.2 protocol error in input message 

On Tuesday 11 December, "Michael Sturm" wrote:

> using omniORB 4.0.7 under VxWorks we often face the following
> malfunction in handling GIOP 1.2 input messages:

If possible, update to the latest cut of omniORB on the omni4_1_develop
branch, or failing that, the omni4_0_develop branch. It's much easier to
help if you're using the latest version of the code.

> "From endpoint: giop:tcp:10.49.x.y:z. Detected GIOP 1.2 protocol error
> in input message. giopImpl12.cc:425. Connection is closed."
> 
> This situation seems to occur in alliance with fragmented GIOP messages
> after having updated client side Java Web Start / JRE to 1.6.0_03 (did
> not see this malfunction under JRE 1.4.x).
> 
> Find the traced GIOP messages leading to this in the attachment
> (traceLevel: 30).

The error is that omniORB has received a fragment message that claims to
be the continuation of a request message, but omniORB thinks it has
already seen the complete request. That could be a bug in omniORB, or it
could be that the client is sending invalid data.

Can you run with traceLevel 40 and also traceThreadId 1. That will make
it easier to see what's going on.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GIOPTrace_2
Type: application/octet-stream
Size: 13833 bytes
Desc: GIOPTrace_2
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20080108/cef6082d/GIOPTrace_2.obj