RP/Tux 8.1 / Tux 9.0 - CORBA - CONCURR_STRATEGY issue
(Doc ID 776734.1)
Last updated on JANUARY 19, 2018
Applies to:Oracle Tuxedo / Tuxedo / 8.1,9.0
Information in this document applies to any platform
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.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document