[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

2481.0. "CORBA_COMM_FAILURE after server stop/restart" by CAMPY::ADEY (PC Server...now there's an oxymoron!) Wed Jun 04 1997 17:22

    I'm getting CORBA_COMM_FAILURE on subsequent requests (after an initial
    successfull request and after the server has been stopped and
    restarted). Per the advice in note 1141 in PAMSRC::OBJECTBROKER, I've
    made sure I'm cleaning up the intermediate variables use along the
    way to getting a narrowed object reference of type 'xxx_var' (where
    'xxx' is the name of my interface).
    
    Any help would be appreciated.
    
    Ken....
T.RTitleUserPersonal
Name		DateLines
2481.1SEND::SLAVINWed Jun 04 1997 19:2814
>    I'm getting CORBA_COMM_FAILURE on subsequent requests (after an initial
>    successfull request and after the server has been stopped and
>    restarted). Per the advice in note 1141 in PAMSRC::OBJECTBROKER, I've
>    made sure I'm cleaning up the intermediate variables use along the
>    way to getting a narrowed object reference of type 'xxx_var' (where
>    'xxx' is the name of my interface).
    
Once a server is stopped and restarted, the client has to detect this 
condition -- generally a failure or timeout from the request, then 
release the object, get a newly bound (bound to the new server location) 
object reference, and then re-try the invoke. When a server restarts 
it uses a new socket or channel. The old one is no longer valid.

you probably missed one of these steps.
2481.2CAMPY::ADEYPC Server...now there's an oxymoron!Wed Jun 04 1997 19:496
    re: Note 2481.1 by SEND::SLAVIN
    
    I forgot to mention in .0 that I AM getting a new object reference
    for every request.
    
    Ken....
2481.3LEMAN::DONALDSONFroggisattva! Froggisattva!Thu Jun 05 1997 08:325
Do you have an unshared server with no auto-start possibilities?

What do trace show you?

John D.
2481.4CAMPY::ADEYPC Server...now there's an oxymoron!Thu Jun 05 1997 15:48183
    re: Note 2481.3 by LEMAN::DONALDSON
    
    > Do you have an unshared server with no auto-start possibilities?
    
    It's a persistent server.
    
    
    > What do trace show you?
    
    Here's a log of the client run. This log contains 2 requests, the first
    was successfull, the 2nd request fails (after I stopped and restarted
    the server):
    
    
    OBB C++ Library Compile Date/Time: Dec 17 1996 19:35:22
    OBB C++ Compile Command: Unknown
    OBB C++ Compile Flags: Unknown
    
    **** 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: D:\win32app\obroker\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                        = redvin
       001. OBB_DEFAULT_NODES                = OBB_LOCAL
    
     Looking for running server:
    
     Looking for servers on node redvin.
    
    *** Load Agent implementation OrbV12
    	FamilyName<3> <OBB>
    ImagePath<26> <%OBB_ROOT\lib\obbagncl.dll>
    	LibraryName: D:\win32app\obroker\lib\obbagncl.dll
    
    *** Load Authentication implementation Trusted
    	FamilyName<3> <TRS>
    ImagePath<26> <%OBB_ROOT\lib\obbsectr.dll>
    	LibraryName: D:\win32app\obroker\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: 552
    ***    Allocated Buffer : 1876
    ***    Transport Status: OBB_SUCCESS (s), Successful completion. 
    ***    Operation Status: OBB_SUCCESS (s), Successful completion. 
    
     Server selected from Registry: 7d0e7a51a2af.02.10.7b.b0.40.00.00.00
    (redvin).
    *** 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: 700
    ***    Allocated Buffer : 1901
    ***    Transport Status: OBB_SUCCESS (s), Successful completion. 
    ***    Operation Status: OBB_SUCCESS (s), Successful completion. 
    
    **** Skip Method Selection, OpInfo Created by STUB
    
    
    **** Implementation Selection
    
    
    **** Callout to method map resolve rtn.
    
    **** 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                        = redvin
       001. OBB_DEFAULT_NODES                = OBB_LOCAL
    
     Looking for running server:
    
     Looking for servers on node redvin.
    *** 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: 552
    ***    Allocated Buffer : 1876
    ***    Transport Status: OBB_SUCCESS (s), Successful completion. 
    ***    Operation Status: OBB_SUCCESS (s), Successful completion. 
    
     Server selected from Registry: 7d0dc917c848.02.10.7b.b0.40.00.00.00
    (redvin).
    *** Request Sent: Synchronous Invoke.
    *** Method: 7a6782d88ad2.02.10.7b.b0.40.00.00.00.
    ***    MethodServerClass: 7a6782d88ad0.02.10.7b.b0.40.00.00.00
    ***    Marshalled Buffer: 1420
    ***    Allocated Buffer : 2668
    ***    Transport Status: OBB_SUCCESS (s), Successful completion. 
    ***    Operation Status: OBB_INV_METHODFAIL (e), Method execution
    failed. 
    
    **** Skip Method Selection, OpInfo Created by STUB
    
    
    **** Implementation Selection
    
    
    **** Callout to method map resolve rtn.
    
    *** Method map resolve rtn not present. Defaulting.
    
    **** 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                        = redvin
       001. OBB_DEFAULT_NODES                = OBB_LOCAL
    
     Looking for running server:
    
     Looking for servers on node redvin.
    *** 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: 552
    ***    Allocated Buffer : 1876
    ***    Transport Status: OBB_SUCCESS (s), Successful completion. 
    ***    Operation Status: OBB_SUCCESS (s), Successful completion. 
    
     Server selected from Registry: 7d0e7a51a2af.02.10.7b.b0.40.00.00.00
    (redvin).
    *** 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: 700
    ***    Allocated Buffer : 1901
    ***    Transport Status: OBB_SUCCESS (s), Successful completion. 
    ***    Operation Status: OBB_SUCCESS (s), Successful completion. 
    
    **** Skip Method Selection, OpInfo Created by STUB
    
    
    **** Implementation Selection
    
    
    **** Automatic Implementation and Server already Bound, Skipping
    Implementation Selection
    
    *** Request Sent: Synchronous Invoke.
    *** Method: 7a6782d88ad2.02.10.7b.b0.40.00.00.00.
    ***    MethodServerClass: 7a6782d88ad0.02.10.7b.b0.40.00.00.00
    ***    Marshalled Buffer: 1420
    ***    Allocated Buffer : 2668
    ***    Transport Status: OBB_INV_TRANSERR (e), Transport error
    `$TransportError$'. 
    ***    Operation Status: OBB_INV_TRANSERR (e), Transport error
    `$TransportError$'.
2481.5RECV::SLAVINThu Jun 05 1997 19:4825
The following makes me think that you are using an old connection to 
the killed server, and not to the new server. Otherwise it should have 
done the Implementation selction and would not have skipped it. If you 
had gone thru a new binding, all of the same steps would have repeated 
for the second call as were done in the first.

>
>    **** Skip Method Selection, OpInfo Created by STUB
>    
>    
>    **** Implementation Selection
>    
>    
>    **** Automatic Implementation and Server already Bound, Skipping
>    Implementation Selection
>    
>    *** Request Sent: Synchronous Invoke.
>    *** Method: 7a6782d88ad2.02.10.7b.b0.40.00.00.00.
>    ***    MethodServerClass: 7a6782d88ad0.02.10.7b.b0.40.00.00.00
>    ***    Marshalled Buffer: 1420
>    ***    Allocated Buffer : 2668
>    ***    Transport Status: OBB_INV_TRANSERR (e), Transport error
>    `$TransportError$'. 
>    ***    Operation Status: OBB_INV_TRANSERR (e), Transport error
>    `$TransportError$'.
2481.6CAMPY::ADEYPC Server...now there's an oxymoron!Fri Jun 06 1997 03:295
    re: Note 2481.5 by RECV::SLAVIN
    
    Should I be calling ORB_Rundown after each request?
    
    Ken....
2481.7LEMAN::DONALDSONFroggisattva! Froggisattva!Fri Jun 06 1997 07:408
>    Should I be calling ORB_Rundown after each request?
    
No. But, (I haven't followed your sequence in detail) if you
cant use an objref that has automatic binding which has already
bound to server1 to talk to server2. You have to release in
between.

John D.
2481.8LEMAN::DONALDSONFroggisattva! Froggisattva!Fri Jun 06 1997 08:0517
Ken, you say you are getting a new objref every time, but
what sequence do you use for this? 

If you just use the naming service, or pick the objref from a file
then you will *not* get a "new" objref just like that. You
really will need to release in between. Otherwise the 'new'
(identical) objref will map directly onto the old one.
Complete with its already established bindings.

On the other hand if you are picking up a (really) different
second objref (perhaps created in a method with BOA::create)
then I you should get new binding and find the new server.

I note, by the way, in your trace, that the last request is
annotated "...already bound...". That's pretty suggestive.

John D.