Simple omniORBpy example throws exception with error 0x41540002

[Samuel]

Hi,

I am trying to get the files from this tutorial to work:
http://www.grisby.org/presentations/py10code.html

Direct link to the files:
http://www.grisby.org/presentations/py10code/adder.idl
http://www.grisby.org/presentations/...adderServer.py

It produces the following error:

$ omniidl -bpython adder.idl && python adderServer.py
Traceback (most recent call last):
File "adderServer.py ", line 23, in <module>
nameRoot = nameRoot._narro w(CosNaming.Nam ingContext)
File "/usr/lib/python2.5/site-packages/omniORB/CORBA.py", line 667,
in _narrow
return _omnipy.narrow( self, dest._NP_Reposi toryId)
omniORB.CORBA.T RANSIENT: Minor: 0x41540002, COMPLETED_NO.

According to Google this might mean "Connect failed", however, I don't
understand why the server would open a connection. I expected it to
simply listen on a socket, but I probably just don't understand how it
works.

Can anyone please explain this?

-Samuel

[Diez B. Roggisch]

Samuel wrote:

Hi,

I am trying to get the files from this tutorial to work:
http://www.grisby.org/presentations/py10code.html

Direct link to the files:
http://www.grisby.org/presentations/py10code/adder.idl
http://www.grisby.org/presentations/...adderServer.py

It produces the following error:

$ omniidl -bpython adder.idl && python adderServer.py
Traceback (most recent call last):
File "adderServer.py ", line 23, in <module>
nameRoot = nameRoot._narro w(CosNaming.Nam ingContext)
File "/usr/lib/python2.5/site-packages/omniORB/CORBA.py", line 667,
in _narrow
return _omnipy.narrow( self, dest._NP_Reposi toryId)
omniORB.CORBA.T RANSIENT: Minor: 0x41540002, COMPLETED_NO.

According to Google this might mean "Connect failed", however, I don't
understand why the server would open a connection. I expected it to
simply listen on a socket, but I probably just don't understand how it
works.

Can anyone please explain this?

It indeed does open a connection - because it wants to register with a
NameServer.

This is basically a bootstrapping-problem. You have to somehow distribute
object references to connect clients to servers. You can do so by using
persistent IORs and configure these for the client. You can also place them
on a network-location somehow.

Or you can configure a name-server for your ORB, and if that name-server is
the same for the server, you can look-up an object reference there. This is
what the example-code tries to do.

So - the easiest solution for now would be to start the omniORB nameserver.
On my ubuntu, that's a matter of installing it via apt.

Diez

[Samuel]

On May 22, 1:54 pm, "Diez B. Roggisch" <[e-mail] b.dewrote:

It indeed does open a connection - because it wants to register with a
NameServer.

Ah, I see now how this works. I happen to run Ubuntu here, so I tried
the following:

- sudo apt-get install orbit-name-server-2
- orbit-name-server-2 &
- Add to /etc/omniORB4.cfg:
InitRef = NameService=IOR :010000002b0000 00...
(where everything starting from "IOR:" is the output given by orbit-
name-server-2.

However, this does not seem to change the behavior. Any hints?

Thanks,
-Samuel

[Diez B. Roggisch]

Samuel wrote:

On May 22, 1:54 pm, "Diez B. Roggisch" <[e-mail] b.dewrote:

>It indeed does open a connection - because it wants to register with a
NameServer.

Ah, I see now how this works. I happen to run Ubuntu here, so I tried
the following:

- sudo apt-get install orbit-name-server-2
- orbit-name-server-2 &
- Add to /etc/omniORB4.cfg:
InitRef = NameService=IOR :010000002b0000 00...
(where everything starting from "IOR:" is the output given by orbit-
name-server-2.

However, this does not seem to change the behavior. Any hints?

Not really. You might try the omniORB mailing list. I've used to be
subscribed there when my CORBA-using project was under active development.
It's a really helpful place, and not too busy so you won't get overwhelmed.

diez

[Samuel]

On May 22, 1:54 pm, "Diez B. Roggisch" <[e-mail] b.dewrote:

It indeed does open a connection - because it wants to register with a
NameServer.

Ah, I see now how this works. I happen to run Ubuntu here, so I tried
the following:

- sudo apt-get install orbit-name-server-2
- orbit-name-server-2 &
- Add to /etc/omniORB4.cfg:
InitRef = NameService=IOR :010000002b0000 00...
(where everything starting from "IOR:" is the output given by orbit-
name-server-2.

However, this does not seem to change the behavior. Any hints?

Thanks,
-Samuel

[Duncan Grisby]

In article <11************ **********@z24g 2000prd.googleg roups.com>,
Samuel <kn******@gmail .comwrote:

[...]

>Ah, I see now how this works. I happen to run Ubuntu here, so I tried
the following:

- sudo apt-get install orbit-name-server-2
- orbit-name-server-2 &
- Add to /etc/omniORB4.cfg:
InitRef = NameService=IOR :010000002b0000 00...
(where everything starting from "IOR:" is the output given by orbit-
name-server-2.

However, this does not seem to change the behavior. Any hints?

I think ORBit is configured to only listen on its proprietary Unix
domain socket protocol by default, not TCP, so omniORB doesn't know
how to talk to it. You should either tell ORBit to listen on TCP
(Google for how), or use omniORB's naming service, which listens on
TCP by default.

Alternatively, you don't particularly need to use a naming service if
you don't want to. You can modify the example to output an IOR string
for the object reference rather than trying to register it in the
naming service. Print the result of orb.object_to_s tring(adderObjr ef)
rather than the naming service stuff.

The example you are looking at was given as a tutorial with me
speaking, so it's a bit light on details of what's going on. You might
find the introduction in the omniORBpy manual more useful:

http://omniorb.sourceforge.net/omnip...iORBpy002.html

or chapter 2 in the PDF version:

http://omniorb.sourceforge.net/omnipy3/omniORBpy.pdf
Cheers,

Duncan.

--
-- Duncan Grisby --
-- du****@grisby.o rg --
-- http://www.grisby.org --

[Samuel]

On May 22, 6:53 pm, Duncan Grisby <[e-mail] wrote:

I think ORBit is configured to only listen on its proprietary Unix
domain socket protocol by default, not TCP, so omniORB doesn't know
how to talk to it. You should either tell ORBit to listen on TCP
(Google for how), or use omniORB's naming service, which listens on
TCP by default.

Yay, after replacing orbit2-nameserver by omniorb4-nameserver
everything works fine.

Thanks a lot for your comment!

-Samuel