[omniORB] Problems with corbaloc
Nigel Rantor
wiggly at wiggly.org
Tue Nov 21 12:06:02 GMT 2006
Hi all,
I've used omniORB before and have decided to use it on a new project I
am a part of. I've used the C++ bindings in the past, now I'm
experimenting with Python.
I joined the list last week and it seems fairly low-volume so I'm going
to post without having been around too long.
I think I have some idea of what the underlying problem may be but I'm
not sure, so here goes.
I want to start up one specific service in such a way that I do not need
a bootstrapping service to get hold of it remotely.
My current solution is to provide the ORB with an endpoint, use the
omniINSPOA to house my service and provide a well-known name to it so
that I can construct a corbaloc URL by knowing the hostname, port and name.
This all works fine. I have no problems doing this, it's groovy. I have
code that works.
My problem is when I try to test these services by killing them I find
that when they come back up and talk to each other I get COMM_FAILURE
errors.
This happens as soon as they start up as they attempt to contact all the
other machines that should be running this service. The weird thing is
that the initiator seems to be okay, but when the receive attempts to
call back to the initiator it dies with a COMM_FAILURE.
To make it more concrete, let's say I have this service running on two
machines, A and B.
1) start service on A
2) service on A attempts to contact B, B is not running yet, fine.
3) start service on B
4) service on B attempts to contact A, A is running and replies.
5) kill service on B
6) start service on B
7) service on B attempts to contact A, A is running and has an operation
invoked on it successfuly by B. A then attempts to invoke an operation
on B and a CORBA.COMM_FAILURE is raised.
If I leave the service on B dead for long enough this problem does not
occur, so I turned tracing on and found that once the service on A gets
to the point where it prints the below message out I can then kill and
restart the service on B and everything works.
--------------------------------------------------------------------
omniORB: Scanning Python thread states.
omniORB: Scanning Python thread states.
omniORB: Scanning Python thread states.
omniORB: Scanning Python thread states.
omniORB: sendCloseConnection: to giop:tcp:172.16.69.250:9991 12 bytes
omniORB: Client connection refcount (forced) = 0
omniORB: Client close connection to giop:tcp:172.16.69.250:9991
omniORB: throw giopStream::CommFailure from
giopStream.cc:835(0,NO,COMM_FAILURE_UnMarshalArguments)
omniORB: Server connection refcount = 1
omniORB: Server connection refcount = 0
omniORB: Server close connection from giop:tcp:172.16.69.250:40464
omniORB: Deleting Python state for thread id 1085389744 (thread exit)
omniORB: AsyncInvoker: thread id = 4 has exited. Total threads = 3
--------------------------------------------------------------------
Now, I don't really have any good ideas, but it does strike me that the
line that says:
--------------------------------------------------------------------
omniORB: throw giopStream::CommFailure from
giopStream.cc:835(0,NO,COMM_FAILURE_UnMarshalArguments)
--------------------------------------------------------------------
isn't actually throwing anything to the app level at the time, I'm
wondering if this is possibly being held over until I next attempt to
invoke an operation on that same connection? in normal operation this
won't happen because the remote servant will have a different port/IOR
over different invocations but in my case the corbaloc URL doesn't change.
Any thoughts or ideas would be greatly appreciated. I'm sure I can add
some code to work around this but I'd really rather have the system Just
Work(tm)
Thanks,
n
More information about the omniORB-list
mailing list