Last updated on NOVEMBER 04, 2016
Applies to:Oracle Tuxedo / Tuxedo / 6,5
Information in this document applies to any platform
I have replicated Customer Problem with Tuxedo 6.5 CTS running on Solaris 2.8 with RP 425. Customer problems: Using an MP application (usmb.ubb) with 9 nodes all nodes have TMSYSEVT. --- They create a failure scenario by disabling an interface on a slave node. On the same slave node they generate a lot of tpacalls with NOREPLY immediately following the disconnect --- Problems faced -- The number of event .SysNetworkFailure and .SysNetworkDropped events posted by the bridge flood the TMSYSEVTs messageq leading to message queue blocking -- Customer would like for BEA to introduce an interval at which Tuxedo posts these events may be scan unit or some other parameter thus not leading to IPC overflow. -- During the event of network failure - the tpcall to TMSYSMIB during polling leads to the TMSYSEVT not being able to process any other events during this timeframe(BLOCKTIME) -- Customer would like BEA to enable TMSYSEVT to get out of the TPCALL quick enough to be able to process the other events - like NetworkFailure etc as these events a very critical to the functioning of the application. All files in attachments -- Customers ubbconfig usmb.ubb usbmd15.truss.out.Z - truss of TMSYSEVT to demonstrate this problem mgqw109.ULOG - ulog of machine with failure. -- My ubbconfig ubbconfig.bea Boot MP application with provided ubb, disable the interface on which the BRIDGE is running - observe ULOG ( with TMTRACE turned on for all servers) or with TRUSS to observe the tpcall wait. To generate many posts by bridge when the interface is down on slave machine run client with 100000 tpacalls (TPNOREPLY) - leads to message queue blocking when BRIDGE does tppost on SysNetworkFailure.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
Million Knowledge Articles and hundreds of Community platforms