Discussion:
[omniORB] can't get rid of omniORB.BAD_PARAM_WrongPythonType
Daschner, Stefan
2007-03-30 22:49:54 UTC
Permalink
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: myIDL.idl
Type: application/octet-stream
Size: 250 bytes
Desc: myIDL.idl
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20070330/c418585e/myIDL.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ServerSeq.py
Type: application/octet-stream
Size: 749 bytes
Desc: ServerSeq.py
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20070330/c418585e/ServerSeq.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ServerSeq.trace
Type: application/octet-stream
Size: 1330 bytes
Desc: ServerSeq.trace
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20070330/c418585e/ServerSeq-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ClientSeq.py
Type: application/octet-stream
Size: 1179 bytes
Desc: ClientSeq.py
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20070330/c418585e/ClientSeq.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ClientSeq.trace
Type: application/octet-stream
Size: 832 bytes
Desc: ClientSeq.trace
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20070330/c418585e/ClientSeq-0001.obj
Duncan Grisby
2007-03-31 17:26:04 UTC
Permalink
On Friday 30 March, "Daschner, Stefan" wrote:

[...]
interface myInterface {
long transmit(in any mesg);
};
[...]
print "the received object: \n", myInStruct
You haven't returned a value, meaning that transmit() returns None. The
IDL says it must return a long. If you return a value, you'll find you
no longer get the exception.

Cheers,

Duncan.
--
-- Duncan Grisby --
-- ***@grisby.org --
-- http://www.grisby.org --
Daschner, Stefan
2007-04-02 19:27:18 UTC
Permalink
Hi Duncan,

thank you very much.
That was a great help for me.

Is there a possibility to get more information in such a case e.g. which parameter is bad ?

Another question:
I noticed that I get the following errors on server side when the client program (normally) ends:
omniORB: Error in network receive (start of message): giop:tcp:127.0.0.1:27199
omniORB: throw giopStream::CommFailure from giopStream.cc:874(0,NO,COMM_FAILURE_UnMarshalArguments)

Do I have to do something to avoid this ?

Cheers
Stefan


-----Urspr?ngliche Nachricht-----
Von: Duncan Grisby [mailto:***@grisby.org]
Gesendet: Samstag, 31. M?rz 2007 13:26
An: Daschner, Stefan
Cc: omniorb-***@omniorb-support.com
Betreff: Re: [omniORB] can't get rid of omniORB.BAD_PARAM_WrongPythonType

On Friday 30 March, "Daschner, Stefan" wrote:

[...]
interface myInterface {
long transmit(in any mesg);
};
[...]
print "the received object: \n", myInStruct
You haven't returned a value, meaning that transmit() returns None. The
IDL says it must return a long. If you return a value, you'll find you
no longer get the exception.

Cheers,

Duncan.
--
-- Duncan Grisby --
-- ***@grisby.org --
-- http://www.grisby.org --
Duncan Grisby
2007-04-05 21:45:34 UTC
Permalink
Post by Daschner, Stefan
Is there a possibility to get more information in such a case
e.g. which parameter is bad ?
Unfortunately, adding the kind of tracking of what value came from where
would really kill performance, so it doesn't do it. You can get some
clue by looking at the line of code referenced in the log message you
get with traceExceptions=1. That will show you what type it was looking
for when it failed.
Post by Daschner, Stefan
omniORB: Error in network receive (start of message): giop:tcp:127.0.0.1:27199
omniORB: throw giopStream::CommFailure from giopStream.cc:874(0,NO,COMM_FAILURE_UnMarshalArguments)
They aren't errors. It's just omniORB reporting and then catching the
connection closure.

Cheers,

Duncan.
--
-- Duncan Grisby --
-- ***@grisby.org --
-- http://www.grisby.org --
Loading...