[omniORB] Remote call hangs

[Daschner, Stefan]

Hi,

I have a server written in python and running on Linux. The C++ client
(running on Linux too) is doing a
remote call which transfers an object to the server. Normally this is
working, but in one special case
resp. for one special object the remote call on client side hangs and
the corresponding method on server side is not
called. In the omniORB trace I can see that in this case the server
sends the following giop message to the client
after receiving the giop message representing the remote call:

omniORB: sendChunk: to giop:tcp:127.0.0.1:13302 68 bytes
omniORB:
4749 4f50 0102 0101 3800 0000 0400 0000 GIOP....8.......
0200 0000 0000 0000 1e00 0000 4944 4c3a ............IDL:
6f6d 672e 6f72 672f 434f 5242 412f 4d41 omg.org/CORBA/MA
5253 4841 4c3a 312e 3000 4540 1600 5441 RSHAL:***@..TA
0100 0000

In the working case the server sends the following GIOP message:

omniORB: sendChunk: to giop:tcp:127.0.0.1:18199 28 bytes
omniORB:
4749 4f50 0102 0101 1000 0000 0400 0000 GIOP............
0000 0000 0000 0000 0000 0000 ............

Does anybody know the reason for this problem ?
How to solve it ?

I'm using omniORBpy-3.0-rc1 on server side and omniORB-4.1.0 on client
side.

Thanks
Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20070315/922a92f0/attachment.htm

[Wernke zur Borg]

Hi,

I have a server written in python and running on Linux. The C++
client (running on Linux too) is doing a
remote call which transfers an object to the server. Normally
this is working, but in one special case
resp. for one special object the remote call on client side
hangs and the corresponding method on server side is not
called. In the omniORB trace I can see that in this case the
server sends the following giop message to the client
after receiving the giop message representing the remote call:

omniORB: sendChunk: to giop:tcp:127.0.0.1:13302 68 bytes
omniORB:
4749 4f50 0102 0101 3800 0000 0400 0000 GIOP....8.......
0200 0000 0000 0000 1e00 0000 4944 4c3a ............IDL:
6f6d 672e 6f72 672f 434f 5242 412f 4d41 omg.org/CORBA/MA
5253 4841 4c3a 312e 3000 4540 1600 5441 RSHAL:***@..TA
0100 0000

In the working case the server sends the following GIOP message:


omniORB: sendChunk: to giop:tcp:127.0.0.1:18199 28 bytes
omniORB:
4749 4f50 0102 0101 1000 0000 0400 0000 GIOP............
0000 0000 0000 0000 0000 0000 ............

Does anybody know the reason for this problem ?
How to solve it ?

I'm using omniORBpy-3.0-rc1 on server side and omniORB-4.1.0 on
client side.


Hi Stefan,

I see two possible reasons:

1. You are not using the same version of your IDL file on both sides;

2. You encode the object at the client side in a way that is invalid
w.r.t. the IDL used at the server side.

In both cases the server would raise a marshal exception, which is what
you see in the response.

It would be helpful if you could post the IDL snippet that corresponds
to the method and the C++ code that is calling the method.

Furthermore, are you sure you have a try{} catch() block around the
method call in the client? Do you evaluate the exception if it happens?

Regards, Wernke

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20070315/6300f9a4/attachment.htm

[Daschner, Stefan]

Hi Wernke,

in fact the IDL files on both sides were not identical.
Now it's working.

The reason why I thought that the remote call hangs was,
that the exception has been catched but not evaluated
i.e. there was no trace output.

Thank you very much !
Stefan



________________________________

Von: Wernke zur Borg [mailto:***@vega.de]
Gesendet: Donnerstag, 15. M?rz 2007 14:50
An: Daschner, Stefan
Cc: omniorb-***@omniorb-support.com
Betreff: RE: [omniORB] Remote call hangs




Hi,

I have a server written in python and running on Linux. The C++ client (running on Linux too) is doing a
remote call which transfers an object to the server. Normally this is working, but in one special case
resp. for one special object the remote call on client side hangs and the corresponding method on server side is not
called. In the omniORB trace I can see that in this case the server sends the following giop message to the client
after receiving the giop message representing the remote call:

omniORB: sendChunk: to giop:tcp:127.0.0.1:13302 68 bytes
omniORB:
4749 4f50 0102 0101 3800 0000 0400 0000 GIOP....8.......
0200 0000 0000 0000 1e00 0000 4944 4c3a ............IDL:
6f6d 672e 6f72 672f 434f 5242 412f 4d41 omg.org/CORBA/MA
5253 4841 4c3a 312e 3000 4540 1600 5441 RSHAL:***@..TA
0100 0000

In the working case the server sends the following GIOP message:

omniORB: sendChunk: to giop:tcp:127.0.0.1:18199 28 bytes
omniORB:
4749 4f50 0102 0101 1000 0000 0400 0000 GIOP............
0000 0000 0000 0000 0000 0000 ............

Does anybody know the reason for this problem ?
How to solve it ?

I'm using omniORBpy-3.0-rc1 on server side and omniORB-4.1.0 on client side.


Hi Stefan,

I see two possible reasons:

1. You are not using the same version of your IDL file on both sides;

2. You encode the object at the client side in a way that is invalid w.r.t. the IDL used at the server side.

In both cases the server would raise a marshal exception, which is what you see in the response.

It would be helpful if you could post the IDL snippet that corresponds to the method and the C++ code that is calling the method.

Furthermore, are you sure you have a try{} catch() block around the method call in the client? Do you evaluate the exception if it happens?

Regards, Wernke

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20070316/7f608700/attachment-0001.htm