[omniORB] omniORB comm failure problems on cygwin

[Heley, Mike]

Hi,

I am having problems with intermittent comm failures on a system ported from
linux to cygwin and would appreciate some help or advice from the list.

The failures appear in the process activation server. This server has an
activate method which forks and execs a new process, returning an ior to an
object in the new process. It does this by waiting for the process to start
up and make a call back to an object in the server, passing back the ior.
The new process finds the object to call from a corbaloc URI passed in an
environment variable. The object has been activated in the omniINSPOA. The
server listens to a fixed port number 9281. This server has worked reliably
on linux in the past.

I have tried with omniORB 4.1.0 and the latest cygwin on windows 2000 and
xp. The behaviour is the same on both with one in ten calls failing in the
following way. The partial traces below are from -ORBtraceTime 1
-ORBtracelevel 25 -ORBtraceInvocations 1

activation server trace

omniORB: 2007-01-23 12:03:06.795375: Dispatching remote call 'activate' to:
root/activatorPOA<activator> (active)
omniORB: 2007-01-23 12:03:06.799375: Adding key<IORCollector.9> (activating)
to object table.
omniORB: 2007-01-23 12:03:06.800375: State key<IORCollector.9> (activating)
-> active
Attempting fork 114
Forked parent 163
Forked child 133
Forked child attempting exec /cygdrive/l/heley/nec/lm/v31/scripts/logmbd 150
omniORB: 2007-01-23 12:04:49.399375: Error in network receive (start of
message): giop:tcp:127.0.0.1:1197
omniORB: 2007-01-23 12:04:49.400375: throw giopStream::CommFailure from
giopStream.cc:874(0,NO,COMM_FAILURE_UnMarshalArguments)
omniORB: 2007-01-23 12:04:49.402375: Server connection refcount = 1
omniORB: 2007-01-23 12:04:49.403375: Server connection refcount = 0
omniORB: 2007-01-23 12:04:49.405375: Server close connection from
giop:tcp:127.0.0.1:1197

child process trace

omniORB: 2007-01-23 12:03:09.057375: Creating ref to remote:
key<IORCollector.9>
target id : IDL:omg.org/CORBA/Object:1.0
most derived id:
omniORB: 2007-01-23 12:03:09.058375: Invoke '_is_a' on remote:
key<IORCollector.9>
omniORB: 2007-01-23 12:03:09.060375: Client attempt to connect to
giop:tcp:localhost:9281
omniORB: 2007-01-23 12:03:09.060375: AsyncInvoker: thread id = 2 has
started. Total threads = 2
omniORB: 2007-01-23 12:03:09.062375: Scavenger task execute.
omniORB: 2007-01-23 12:03:09.080375: Client opened connection to
giop:tcp:127.0.0.1:9281
omniORB: 2007-01-23 12:03:09.081375: sendChunk: to giop:tcp:127.0.0.1:9281
89 bytes
omniORB: 2007-01-23 12:03:10.145375: SocketCollection idle. Sleeping.


Had the error not occured, the activated process goes on to call a method on
the IORCollector object to pass the ior back. I presume the is_a call which
fails is a necessary corba infrastructure call.

I also tried using both the loopback address and the machines network ip
address to no avail.

Any ideas appreciated. Thanks.

Mike Heley.




********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20070123/0e51f4c4/attachment.htm

[Duncan Grisby]

Post by Heley, Mike
The failures appear in the process activation server. This server has an
activate method which forks and execs a new process, returning an ior to an
object in the new process. It does this by waiting for the process to start
up and make a call back to an object in the server, passing back the ior.
The new process finds the object to call from a corbaloc URI passed in an
environment variable. The object has been activated in the omniINSPOA. The
server listens to a fixed port number 9281. This server has worked reliably
on linux in the past.

Forking from multi-threaded processes is often problematic. I wouldn't
be surprised if cygwin gets it wrong occasionally.

It's not especially trivial to do, but you could try pre-forking a child
before you start omniORB in the activation server, then send messages to
that child through a pipe. The child can remain single threaded and fork
the children as necessary. Ugly, but safer than forking once omniORB is
going.

Cheers,

Duncan.