[omniORB] Name federation woes
baileyk@schneider.com
baileyk@schneider.com
Tue May 28 21:36:01 2002
--0__=86256BC7007087638f9e8a93df938690918c86256BC700708763
Content-type: text/plain; charset=us-ascii
----- Forwarded by Kendall Bailey/Schneider on 05/28/2002 03:29 PM -----
Kendall Bailey
To: "Visscher, Bruce" <VISSCHB@rjrt.com>
05/28/2002 cc:
02:38 PM Fax to:
Subject: Re: [omniORB] Name federation woes(Document
link: Kendall Bailey)
I tried to federate omniNames and the Orbix2000 name service. It worked
great until I had to recycle the omniNames service while Orbix was also
down. omniNames appeared to need all other name services up for which
contexts were bound into omniNames. This was with omniORB 3.0.4. I
haven't tried with 4.0. I have spent some time trying to track down and
correct the problem. I think omniNames is doing an is_a() call and that
throws a COMM_FAILURE since the other service is not running. I wanted to
get omniNames to defer the _narrow() call on the bound contexts' IORs until
it was absolutely necessary (if the IOR is in the omniNames' log file it
must have been narrowed successfully some time in the past, right?). I
haven't gotten very far with a patch. It's been sort of a learning
experience for me (that's why I didn't post the problem...)
I understood right away that federating two omniNames instances would be a
problem. If each had a context bound from the other, neither would start
unless the other was already running. The omniNames log file format was
simple to understand. I manually editted out the bound contexts which were
hosted by Orbix2000 and then omniNames started right up.
Kendall
"Visscher, Bruce"
<VISSCHB@rjrt.com> To: <omniorb-list@realvnc.com>
Sent by: cc:
omniorb-list-admin@r Fax to:
ealvnc.com Subject: [omniORB] Name federation woes
05/28/2002 11:51 AM
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 = 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") == 0) {
28989
28990 CosNaming::NamingContext_var nc2
28991 = 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
(See attached file: InterScan_Disclaimer.txt)
--0__=86256BC7007087638f9e8a93df938690918c86256BC700708763
Content-type: application/octet-stream;
name="InterScan_Disclaimer.txt"
Content-Disposition: attachment; filename="InterScan_Disclaimer.txt"
Content-transfer-encoding: base64
Q09ORklERU5USUFMSVRZIE5PVEU6ICBUaGlzIGUtbWFpbCBtZXNzYWdlLCBpbmNsdWRpbmcgYW55
IGF0dGFjaG1lbnQocyksIGNvbnRhaW5zIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIGNvbmZpZGVu
dGlhbCwgcHJvdGVjdGVkIGJ5IHRoZSBhdHRvcm5leS1jbGllbnQgb3Igb3RoZXIgbGVnYWwgcHJp
dmlsZWdlcywgYW5kL29yIHByb3ByaWV0YXJ5IG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uICBJZiB5
b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBtZXNzYWdlIG9yIGFuIGF1
dGhvcml6ZWQgYXNzaXN0YW50IHRvIGFuIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlm
eSB0aGUgc2VuZGVyIGJ5IHJlcGx5aW5nIHRvIHRoaXMgbWVzc2FnZSBhbmQgdGhlbiBkZWxldGUg
aXQgZnJvbSB5b3VyIHN5c3RlbS4gIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBv
ciByZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGFuZC9vciBhbnkgb2YgaXRzIGF0dGFjaG1l
bnRzIChpZiBhbnkpIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3QgYXV0aG9yaXplZCBh
bmQgbWF5IGJlIHVubGF3ZnVsLg0KDQo=
--0__=86256BC7007087638f9e8a93df938690918c86256BC700708763--