RP/TUX 7.1 - multi-threaded server's rcv buffer re-allocation mechanism is broken... - CR034654 (Doc ID 766648.1)

Last updated on NOVEMBER 04, 2016

Applies to:

Oracle Tuxedo / Tuxedo / 7.1
Information in this document applies to any platform

Goal

DESCRIPTION:

Problem found in TUX 7.1 (without patch or with RP004) multi-threaded server on HPUX11 platform.

For the message size ~4.5k to 9k bytes big, the multi-threaded server's rcv buffer re-allocation mechanism is not
working.  If you do a truss (tusc for HPUX11) on the server, you will see msgrcv() repeatedly running into E2BIG
errors which cause a lot of performance penalty.  We suppose to have an internal rcv buffer re-allocation hystersis
mechanism to track/reuse the previous allocated rcv buffer to eliminate such repeated E2BIG errors.  Evidentially,
such hystersis mechanism does not kick in for message size ~4.5k to 9k bytes big.  For message size > 9kbytes seems
working OK.

Testcase located in lclab1.beasys.com:/nfs/home3/qchan/lchp12/187436/091300/simp71
- modify the perftest.c to send 5k bytes message;
- run '. ./runbuild' to rebuild everything.  Note: the key is to have 'buildserver -t' and the MAXDISPATCHTHREADS>1
in ubb.
- tmboot -y and run a (or multiple) copy of perftest
- use the tusc (Trace Unix System Call ulttlity) to get a trace on simpserv like:
../tusc/tusc -h -E -f -v -u -R -p <simpserv pid>
==> you will see msgrcv will continuously repeatedly run into E2BIG errors.
Repeat the above steps with perftest sending 10000bytes message and you will not see those E2BIG errors.

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