[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference pamsrc::objectbroker_development

Title:ObjectBroker Development - BEA Systems' CORBA
Notice:See note 2 for kit locations; note 4 for training
Moderator:RECV::GUMBELd
Created:Thu Dec 27 1990
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2482
Total number of notes:13057

2399.0. "CORBA_NO_IMPLEMENT on COS name lookup?" by MIASYS::DLUGOSZ (My reality check just bounced) Fri Dec 13 1996 18:26

T.RTitleUserPersonal
Name
DateLines
2399.1See not 2379 - need a Fix MIASYS::DLUGOSZMy reality check just bouncedFri Dec 13 1996 20:3611
2399.2See 2359.1SEND::PEREZThe InFAMous EightFri Dec 13 1996 21:2510
2399.3NQOS01::nqsrv226.nqo.dec.com::WorkbenchSat Dec 14 1996 02:486
2399.4YikesMIASYS::DLUGOSZMy reality check just bouncedSat Dec 14 1996 13:0212
2399.5REQUE::ctxobj.zko.dec.com::PATRICKSun Dec 15 1996 12:0312
2399.6Can you be more specific on the nature of problem?MIASYS::DLUGOSZMy reality check just bouncedMon Dec 16 1996 14:083
2399.7REQUE::ctxobj.zko.dec.com::PATRICKTue Dec 17 1996 11:4710
2399.8CAMPY::ADEYIs there a 'Life for Dummies'?Fri Feb 07 1997 18:32165
Hello, I'm having a problem with a client on a Windows 95 machine when
trying to resolve an object reference in the local advertisement registry.

The problem is I'm not getting anything back from the
CosNaming_NamingContext_resolve call.

One thing I'm noticing is that the Naming Service Implementation is not
automatically started (usually indicated by a DOS box popping up) on the
client. I've checked and double-checked the local advertisement registry,
it does contain the object reference I'm after ("CSIOBJ"). Here's the 
    output of a 'obbshadv':
    
    
    Advertisements registered.
    
       Implementation Name   
      --------------------- 
      ObjectBrokerRegistryServer                  
          ImplementationId:     665780be114c.0c.f3.4d.00.00.00.00.00   
    
    Advertisements registered.
    
      Object Name   
      ------------- 
      DCP_SERVER                                  
          ObjectReference:     
    DEC::~00001472a44097119f600000c3b1700000000000000082 
    3009714c9a00000c3b1700000000000000700000823009714c9a00000c3b17000000000002010000
    7fe~BIGBRD~~~|
    
      DCP_FACTORY                                 
          ObjectReference:     
    DEC::~000014747dc117172e700000c3b17000000000000000eb 
    9a1071ca8500000c3b1700000000000000100000eb9a1071ca8500000c3b17000000000002010000
    180~BIGBRD~~~|
    
      ITEMFACTORY                                 
          ObjectReference:     
    DEC::~10002034365c57836c300000c3b1700000000000000007 
    891571734f000002c77d48fa0000000000110000000000107891571744f000002c77d48fa0000000
    00010000007891571734f000002c77d48fa00000002010000180~BIGBRD~~~%00000%|
    
      ORDERFACTORY                                
          ObjectReference:     
    DEC::~10002404365c57837c300000c3b1700000000000000007 
    891571754f000002c77d48fa0000000000210000000000207891571774f000002c77d48fa0000000
    000107891571784f000002c77d48fa000000000020000007891571754f000002c77d48fa00000002
    0100002c0~BIGBRD~~~%00000%|
    
      INVENTMANAGE                                
          ObjectReference:     
    DEC::~10003144365c57838c300000c3b1700000000000000007 
    891571794f000002c77d48fa00000000004100000000004078915717c4f000002c77d48fa0000000
    0003078915717d4f000002c77d48fa00000000004078915717a4f000002c77d48fa0000000000107
    8915717b4f000002c77d48fa000000000020000007891571794f000002c77d48fa00000002010000
    4b0~BIGBRD~~~%00000%|
    
      INVENTLOG                                   
          ObjectReference:     
    DEC::~10002774365c57839c300000c3b1700000000000000007 
    8915717e4f000002c77d48fa0000000000310000000000307891571814f000002c77d48fa0000000
    0003078915717f4f000002c77d48fa0000000000107891571804f000002c77d48fa0000000000200
    000078915717e4f000002c77d48fa000000020100003a0~BIGBRD~~~%00000%|
    
      CSIOBJ                                      
          ObjectReference:     
    DEC::~10002038042857a81a900000c3b17000000000000000d8 
    82677ad08a000002107bb04000000000001100000000001d882677ad28a000002107bb0400000000
    000100000d882677ad08a000002107bb04000000002010000180~BIGBRD~~~%00000%|
    
      BANKACCOUNT                                 
          ObjectReference:     
    DEC::~10003142c7b767ac4b300000c3b1700000000000000005 
    68d76f15e4000002c77d486d000000000041000000000040568d76f18e4000002c77d486d0000000
    00030568d76f19e4000002c77d486d000000000040568d76f16e4000002c77d486d0000000000105
    68d76f17e4000002c77d486d00000000002000000568d76f15e4000002c77d486d00000002010000
    4b0~BIGBRD~~~%00000%|
    
    

A QuickStart client with the object reference hard-coded works just fine.

The same executable DOES work on another Win95 machine.

I get the same behavior under V2.7-11 and V2.7-10 (the current version).


Here's a trace log:


**** Skip Method Selection, OpInfo Created by STUB


**** Implementation Selection


**** Callout to method map resolve rtn.

*** Method map resolve rtn not present. Defaulting.

*** Load Network implementation MicrosoftTCP
	FamilyName<5> <TCPIP>
ImagePath<24> <%OBB_ROOT\lib\trnwsk.dll>
	LibraryName: C:\Program Files\ObjectBroker\lib\trnwsk.dll

**** Server Instance Selection

 Selection policy defaulting to advertisements, local_node, default_nodes.

 Context scope default to USER.

 Get Server Selection Node List:

 Possible server selection nodes: <2>
   000. OBB_LOCAL                        = kda.mlo.dec.com
   001. OBB_DEFAULT_NODES                = bigbrd

 Looking for running server:

 Looking for servers on node kda.mlo.dec.com.

*** Load Agent implementation OrbV12
	FamilyName<3> <OBB>
ImagePath<26> <%OBB_ROOT\lib\obbagncl.dll>
	LibraryName: C:\Program Files\ObjectBroker\lib\obbagncl.dll

*** Load Authentication implementation Trusted
	FamilyName<3> <TRS>
ImagePath<26> <%OBB_ROOT\lib\obbsectr.dll>
	LibraryName: C:\Program Files\ObjectBroker\lib\obbsectr.dll
*** Request Sent: Synchronous Invoke.
*** Method: 65e448f20f7c.0c.7e.0b.00.00.00.00.00.
***    MethodServerClass: 65e448ecbd2c.0c.7e.0b.00.00.00.00.00
***    Marshalled Buffer: 568
***    Allocated Buffer : 1894
***    Transport Status: OBB_SUCCESS (s), Successful completion. 
***    Operation Status: OBB_INV_METHODFAIL (e), Method execution failed. 

 Looking for servers on node bigbrd.
*** Request Sent: Synchronous Invoke.
*** Method: 65e448f20f7c.0c.7e.0b.00.00.00.00.00.
***    MethodServerClass: 65e448ecbd2c.0c.7e.0b.00.00.00.00.00
***    Marshalled Buffer: 560
***    Allocated Buffer : 1885
***    Transport Status: OBB_SUCCESS (s), Successful completion. 
***    Operation Status: OBB_SUCCESS (s), Successful completion. 

 Server selected from Registry: 7a8dd6420789.0c.3b.17.00.00.00.00.00 (bigbrd).
*** Request Sent: Synchronous Invoke.
*** Method: 7368090a6e58.02.10.1f.a0.9b.00.00.00.
***    MethodServerClass: 508c0a7f9532.1d.40.33.45.06.70.2e.d9
***    Marshalled Buffer: 708
***    Allocated Buffer : 1910
***    Transport Status: OBB_SUCCESS (s), Successful completion. 
***    Operation Status: OBB_INV_NOTAUTHORIZED (e), Client user is not
authorized to access server. 


The last error above is strange, because I can see running implementations
on the remote server using the local Implementation Manager utility
(indicating to me that the proxy is ok).

Thanks for any ideas.

Ken....
2399.9REQUE::BOWERPeter Bower, ObjectBrokerSat Feb 08 1997 10:498
    Are there any Naming Service implementations running on bigbird ?
    If the implementation has been running for a long time, then
    the proxy may have been added after the implementation started.
    This would account for the client not authorized errors - either
    restart the implementation or use the obbmset -A -U option to 
    cause the server to refresh its cache of proxies.
    
    
2399.10CAMPY::ADEYIs there a 'Life for Dummies'?Mon Feb 10 1997 12:5511
    re: Note 2399.9 by REQUE::BOWER
    
    I don't think it's a proxy issue, because a) a client with a hard-coded
    object reference works fine, b) I can see the running implementations
    on the server from the Implementation Manager utility on the client 
    (which you can't without a proxy).
    
    Why is it going to the server to resolve the object reference (it's in 
    the local advertisement registry)?
    
    Ken....
2399.11CAMPY::ADEYIs there a 'Life for Dummies'?Tue Feb 11 1997 12:365
    re: Note 2399.9 by REQUE::BOWER
    
    Any more ideas? Thanks.
    
    Ken....
2399.12CAMPY::ADEYIs there a 'Life for Dummies'?Wed Feb 12 1997 01:149
    re: Note 2399.9 by REQUE::BOWER
    
    Maybe this might help...if I delete the user context object, the Naming
    Service implementation automatically starts up and the
    CosNaming_NamingContext_resolve call succeeds. 
    
    Thanks for any ideas.
    
    Ken....
2399.13REQUE::BOWERPeter Bower, ObjectBrokerSat Feb 15 1997 10:4030
    The CosNaming api is just an OBB client. Therefore, it uses the
    same mechanisms to determine the server. It looks first on the
    local node and then the value of default nodes in the user
    context object. By deleting the user context object, you are
    removing the value of the default nodes and therefore the
    client does not find a running implementation on the local node
    and then starts one up. 
    
    Implementing the CosNaming api as a client allows you to have a
    central CosNaming server. 
    
    With a normal client, you could define a method map to control
    the selection policy. However, the CosNaming client has been
    compiled with a static method map that you can not control.
    
    Therefore, there are two options. The first is to determine why
    the server is rejecting the invoke on bigbird. You could try 
    stopping the CosNaming server on bigbird.
    
    The second is to control the server selection through the context object.
    For this option,
    
    	get a default context
    	delete the OBB_DEFAULT_NODES property
    	invoke the CosNaming routines
    	delete the context
    
    	do the normal invoke
    
    
2399.14CAMPY::ADEYIs there a 'Life for Dummies'?Mon Mar 17 1997 18:078
    Not using a context object, under Windows 95 my client causes a Naming
    Service Implementation to start up if one's not running. Under Windows
    NT Workstation 4.0 and OBB V2.7-11, a Naming Service Implementation
    is not started, resulting in an object name resolution failure.
    
    Any ideas would be appreciated.
    
    Ken....
2399.15SEND::SLAVINMon Mar 17 1997 18:128
this is discussed in the following notes

2082  VARESE::ARGENTO      11-JAN-1996    14  Autostart on Alpha NT
2135  STKAI1::ANDERSSONB   14-MAR-1996    10  Problem getting Principal in au
2217  STOWOA::TALLURI      21-MAY-1996    12  Autostarting server on Windows 
2231  STOWOA::TALLURI       3-JUN-1996     6  GUI for autostartup server on W
2305   LEMAN::DONALDSON    23-AUG-1996     1  W95 Windows 95 and Server start
2399.16CAMPY::ADEYIs there a 'Life for Dummies'?Tue Mar 18 1997 01:025
    re: Note 2399.15 by SEND::SLAVIN
    
    Thanks for the pointers, but these don't discuss my problem.
    
    Ken....
2399.17Is any server startup occuring on the NT machine?RECV::VLATASWARNING: Do not swallow the battery doorTue Mar 18 1997 10:0121
    
    Can you post a trace log of the client failing in the NT case.
    
    Is the user account that the server is to be started with on the
    NT machine in the Administrator group on the NT machine?
    
    Also, is any server startup happening on the NT machine? Try the
    following to verify a server startup occurs:
    
    	- Start OBBADMIN GUI on NT machine
        - Enter in: obbmerge -n local-host-name advertisement
        - Enter in: obbmsho
    
    Note that for local-host-name you need to give the _full_ tcp name
    for the host (ie: foo.zko.dec.com).
    
    The obbmerge should cause an ObjectBrokerRegistryServer to startup. 
    If the registry server doesn't startup there is a more basic problem
    here.
    
    Tony
2399.18SEND::SLAVINTue Mar 18 1997 12:192
NT startup problems are discussed in these. the name server is a 
regular server. 
2399.19CAMPY::ADEYIs there a 'Life for Dummies'?Tue Mar 18 1997 12:4023
    re: Note 2399.17 by RECV::VLATAS
    
    Thanks for the tips. 
    
    > Is the user account that the server is to be started with on the
    > NT machine in the Administrator group on the NT machine?
    
    Would this be the account I was logged in under when I installed OBB?
    
    
    > Also, is any server startup happening on the NT machine?
    
    When I excecute the "obbmerge -n redvin.mlo.dec.com advertisement"
    command, I get:
    
    OBB_REG_NOREMOTE <e>, The registry on system 'redvin.mlo.dec.com' is
    not reachable.
    
    
    Thanks again.
    
    Ken....
    
2399.20CAMPY::ADEYIs there a 'Life for Dummies'?Tue Mar 18 1997 17:407
    re: Note 2399.17 by RECV::VLATAS
    
    A removal and re-install of OBB has fixed my problem.
    
    Thanks.
    
    Ken....
2399.21naming service, NO_IMPLEMENTSTKAI1::LANKI_TTapio LankiTue Apr 29 1997 13:0259
    I need some help with the Naming Service.
    
    Environment: NT4.0, VC++4.2, OBB 2.7-11, two NT boxes talking to
    one another using OBB.
    
    NTbox1: contains a running server (one implementation) and a
    manually started naming service.
    
    NTbox2: running a test client (character based GUI) in a single
    process. Everything works fine, the client obtains an objref
    from the naming service in NTbox1, and produces output with correct
    results.
    
    Our real client application is a web browser talking to a .dll
    (ISAPI, not CGI) which contains C++ objects encapsulating the calls
    to the stubs. The call to the naming service resides inside a 
    constructor of a C++ object. After the CosNamingContext_resolve,
    OBB_exception_errortext(&local_ev, OBB_FORMAT_80) produces the 
    following output: OBB_INV_HOSTNOTFND (e), A host node could not be
    found to execute the request. 
    - OBB_COM_UNKERRTXT (e), unknown error: '$ErrorText$'.
    - OBB_COM_UNKERRTXT (e), unknown error: 'The specified domain did not
    exist.'.
    
    Why does the ascii based program work, but the .dll does not? 
    I've tried to change proxies, security, authorization etc etc.
    At the moment I'm totally out of ideas.
    
    I experience a couple of pecualiarities:
    
    1) When I merge the advertisement and start the naming service on
    NTbox2, I *do* get an object reference, but the method invocation
    fails.
    
    2) When I start everything on NTbox2, *everything* works.
    
    
    This is how it looks like when we try to use both NT machines
    
    obbshpxy (on NTbox1)
    --------
    Local User		Remote User	Remote Host
    -----------------------------------------------
    ds2831		*		*
    
    
    OBB_DEFAULT_NODES in the user context object (NTbox2, e.g., the client)
    sedpc3 (which is NTbox1)
    sedpc95 (NTbox2)
    
    
    
    Could it be the compiler?
    Something about .dll that I do not know?
    
    
    Slightly desperate,
    Tapio Lanki
    Digital Consulting, Stockholm
2399.22CAMPY::ADEYPC Server...now there's an oxymoron!Tue Apr 29 1997 16:236
    re: Note 2399.21 by STKAI1::LANKI_T "Tapio Lanki"
    
    Is the user context object file in the same directory as the browser
    .EXE?
    
    Ken....