RP/Tux 8.1 / Tux 9.0 - CORBA - CONCURR_STRATEGY issue

(Doc ID 776734.1)

Last updated on NOVEMBER 04, 2016

Applies to:

Oracle Tuxedo / Tuxedo / 8.1,9.0
Information in this document applies to any platform

Goal

Environment:
Tux Version 8.1, 32-bit, Patch Level 165 AIX 5.2

Problem description:
Customer has a multi-threaded server that using DEFAULT CONCURR_STRATEGY which is set to  PER_OBJECT .
Yet when they backup the threads they are seeing the following errors.  

154256.gaspra!TUXOIDServer.1777876.772.2: TPFW_CAT:205: ERROR: Illegal recursive call on CORBA Object. 
Interface = IDL:CorbaOidGeneratorServer/OidGeneratorInterface:1.0, OID = OidGenerator_oid

They basically see the following behavior:

The remote Corba client request/invocation will be sent to one of the two server processes via ISL/ISH. 
If this process is not executing a request with the SAME OID, then it will process this request. 
If this server process is processing a request with the SAME OID, 
then the request will be routed to a different server process to be executed. 
If this second server process is not executing a request with the SAME OID, 
then it will process this request. 
If this server process is processing a request with the SAME OID and there are no other server processes 
available, then a TPFW_CAT:205:ERROR message is entered in the ULOG file 
(illegal recursive call on CORBA object, Interface=<interface name>, OID=<object ID>).
This behavior suggests that multi-threading Tuxedo servers with parallel objects (concurrency_policy ( user_controlled
);)is meaningless 
because only unique OIDs can run in more than one thread in the same server process.

Test reproducer attached to the CR :
1.  Edit  'setenv.cmd' to set up  environment variables.

2.  Execute 'setenv.cmd'

3.  Execute 'nmake -f makefile.nt' and then make changes in ubb to match your env

4.  Execute the file 'runme.cmd'

5.  The results are displayed in the ULOG file.  See ERROR #205.

6.  Execute 'tmshutdown -y'

7.  Execute 'nmake -f makefile.nt clean'

As a workaround the following has been suggested :

Change concurr_strategy to
CONCUR_STRATEGY = PER_REQUEST
Modified version (by Todd Little) is attached. 
It seems to run perfectly. 
The basic changes were to add the above line to the UBB,  
also to run multiple servers, although a single server  also works fine, 
to change the activation policy in the ICF to process which means the objects dont deactivate, 
and to add the _is_reentrant() method to the simple_i.h and simple_i.cpp files to indicate that the servants are
reentrant.

Nevertheless customer insists on having CONCURR_STRATEGY set to PER_OBJECT and this seems to fail.

Solution

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms