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

Conference tuxedo::dce-products

Title:DCE Product Information
Notice:Kit Info - See 2.*-4.*
Moderator:TUXEDO::MAZZAFERRO
Created:Fri Jun 26 1992
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2269
Total number of notes:10003

2241.0. "No exception after comm failure with DCE1.1c and TCP" by VIRGIN::BILL (BILL is my lastname !!!) Tue May 06 1997 08:33

Hi all

A customer in Sweden is having a strange problem with a DCE 1.1c 
on WNT40 Build 1381 client programm. It seems that exceptions are 
not handled using the TCP protocol.

The following scenario is reproducible: ( I used an modified version
of the RPC Test1 sample shipped with DCE ADK)

- ServerApplication starts

- Client Application binds via String Binding and issues RPC calls
	(using TCP protocol)

- Now we stop the server

- The ClientApplication starts to eat up CPU time (95%) and exits
  without any message !!
  If we run the same client on a DUNIX 3.2 / DCE 133 we get immediately
  an exception: rpc_s_connection_closed.

This is the critical part in the client:
(please modify the RPC test1 sample to reproduce the error)

    TRY {
      test1_add (binding_handle, i, i, &n);   // actual RPC call
    }
    CATCH_ALL {
      if (exc_get_status (THIS_CATCH, &status) == 0 )
        printf("Exception calling server: %s\n",strerror(status));
    }
    ENDTRY

It's never coming to the CATCH_ALL statement. I put some debug
statements into the client stub. I could see that after the stop
of the server, the FINALLY section was entered immediately and
also the call rpc_ss_ndr_clean_up was done. The
next call "rpc_ss_call_end_2" uses up the CPU and exits the program
without proceding in the CATCH_ALL of the main program.


It is not depending on the server application. If I run the server
on a DUNIX system and the client on NT it's the same behaviour.
If the client runs on a DUNIX system it works ok !


Any know problems ? My collegues from Sweden will file an IPMT
on this subject.

Thanks for any help

Marco


T.RTitleUserPersonal
Name
DateLines