[omniORB] OpenVMS problem

[Bruce Visscher]

Duncan,

Thanks for you reply.

On Mon, Apr 20, 2009 at 5:06 AM, Duncan Grisby <duncan at grisby.org> wrote:
>
> On Friday 27 March, Bruce Visscher wrote:
>
> > Recently I have discovered a problem on the OpenVMS platform that only occurs
> > in omniORB 4(12).  It did not occur in omniORB 2 or 3.
> >
> > Occasionally, a server will display the following:
> >
> > omniORB: Error return from select(). errno = 65535
> > omniORB: Unrecoverable error for this endpoint: giop:tcp:xx.xx.xx.xx:xxxxx, it
> > will no longer be serviced.
>
> [...]
> > I am wondering what would happen if I turn off the timeout in select
> > altogether.  (Iirc, you do that by passing a null in place of the timeout*)
> > Would this just make it more difficult to have a graceful shutdown?  (The way
> > around that would be to issue a shutdown on the listening socket from a
> > different thread it seems to me.)  Is there a way to do this already?
>
> Sorry for the delay in replying. It's not a good idea to remove the
> timeout in select(), since that way you will sometimes fail to watch
> connections when you should do. The timeout is used to cause the code to
> rescan the set of file descriptors to watch.
>
> Does it work if you modify the code to just carry on if you get that
> error?  i.e. duplicate the way it handles EBADF.

I had thought about doing that but wasn't sure it would lead to a
desirable outcome.  I have developed a reproducer that works fairly
well so I will give this a try.

One thing I have done is to modify the code that reports
"Unrecoverable error for this endpoint: giop:tcp:xx.xx.xx.xx:xxxxx, it
will no longer be serviced." to actually shut down the ORB at that
point.  For my purposes, it would be better to shut down a server that
no longer listens.  It's a little bit of a sledge hammer, but it
works.  I could submit a patch if you think it would benefit others.

Of course, I am pretty sure this is an OS level bug and I am trying to
get a resolution on that.

>
> Cheers,
>
> Duncan.
>
> --
>  -- Duncan Grisby         --
>  -- duncan at grisby.org     --
>   -- http://www.grisby.org --

Bruce Visscher