[omniORB] Name federation woes

[Visscher, Bruce]

This is a multi-part message in MIME format.

------=_NextPartTM-000-5fa8591b-a894-4934-b5d0-d3ac4bd998ad
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello list,

I have recently encountered some problems with omniNames after having =
federated the name service.

Prior to federating the name service we had been running with a single =
omniNames server running on an OpenVMS VAX (currently omniORB
2.8.0 on OpenVMS 7.1).  The name service clients are all omniORB =
applications (no other ORBs) running on OpenVMS VAX, OpenVMS Alpha,
and Windows NT/2000.  This configuration has worked very well for a =
number of years with very few problems.

However, now that we have begun to federate the name service we have =
encountered problems that I have never seen before.  We have
added another omniNames server running on OpenVMS Alpha 7.3 running =
omniORB 3.0.4.  I do not use the root context to perform the
federation. Rather, we bind individual contexts remotely on an as needed =
basis using the 'nameclt -advanced bind_context' option.
This has the advantage that I can transparently move a naming context by =
using the same name on a different node.  Note that we have
these "symbolic links" pointing in both directions.

This worked great until the VAX was restarted.  After that happened, =
both name services appeared to be hung.  Next, I tried shutting
down the name service running on the Alpha.  The next time I tried to =
start up omniNames on the VAX, I got this:

$ omniNames
%CXXL-F-TERMINATE, terminate() or unexpected() called
%TRACE-F-TRACEBACK, symbolic stack dump follows
module name     routine name                     line       rel PC    =
abs PC
CXXL$VMS_CXX_EX CXXL$MAIN_DISPATCH              14500      000000CE  =
000151C2
                                                           000CDF3C  =
000CDF3C
----- above condition handler called with exception 05F7841C:
%CXXL-F-RETHROW, Exception rethrown at PC =3D 00261A4C
----- end of exception message
                                                           0029ECB7  =
0029ECB7
                                                           002618E7  =
002618E7
                                                           00261A4C  =
00261A4C
                                                           0024F211  =
0024F211
LOG             omniNameslog::getBind           28990      00000AB7  =
000124C7
LOG             omniNameslog::init              28486      000007D9  =
0000F9B5
OMNINAMES       main                            26732      000002C3  =
00005633
                                                           0001529A  =
0001529A
                                                           002D371E  =
002D371E
                                                           002C94DD  =
002C94DD

The location of the exception in omniNameslog::getBind where the =
exception is occuring is where it attempts to narrow the context:

          28928
          28929 void
          28930 omniNameslog::getBind(istream& file)
          28931 {
          28932   //
[...]
          28987
          28988   if (strcmp(bindingType, "ncontext") =3D=3D 0) {
          28989
          28990     CosNaming::NamingContext_var nc2
          28991       =3D CosNaming::NamingContext::_narrow(o);
          28992     if (CORBA::is_nil(nc2)) {
          28993       cerr << ts.t() << "bind: IOR not a NamingContext." =
<< end
          28994       throw ParseError();
          28995     }
          28996     nc->rebind_context(name, nc2);
          28997
          28998   } else {
          28999

I finally had to shutdown both name servers and start over by deleting =
the omninames-<node>.* files and restart from scratch via
'omniNames -start'.

Has anyone else encountered problems like these in federating the name =
service using omniNames?  Would a newer version of omniORB
solve either of these problems?

Bruce

------=_NextPartTM-000-5fa8591b-a894-4934-b5d0-d3ac4bd998ad
Content-Type: text/plain;
	name="InterScan_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="InterScan_Disclaimer.txt"

CONFIDENTIALITY NOTE:  This e-mail message, including any attachment(s), contains information that may be confidential, protected by the attorney-client or other legal privileges, and/or proprietary non-public information.  If you are not an intended recipient of this message or an authorized assistant to an intended recipient, please notify the sender by replying to this message and then delete it from your system.  Use, dissemination, distribution, or reproduction of this message and/or any of its attachments (if any) by unintended recipients is not authorized and may be unlawful.


------=_NextPartTM-000-5fa8591b-a894-4934-b5d0-d3ac4bd998ad--