SMX pipes are continually allocated in HDR pair for each call to
dr_IsSecondaryInCheckpoint after HA_ALIAS is set dynamically on
secondary.
Over time, you will see an accumulation of messages like this in
the online.log:
10:31:33 smx creates 1 transports to server wmtsecha
11:04:04 smx creates 1 transports to server wmtsecha
You will also start to see an accumulation of threads like these
in onstat -g ath:
1780 51a92628 44de7188 3 cond wait smx
pipe1 10cpu smxsnd wmtsecha
1781 51a929b0 44de7a68 3 sleeping secs:
8 1cpu smxrcv wmtsecha
1782 51a92d38 44de8348 1 sleeping secs:
1 9cpu smxRecvSnd
5323 52a78868 44de5fc8 3 cond wait smx
pipe1 10cpu smxsnd wmtsecha
5324 529b9028 44de68a8 3 sleeping secs:
8 10cpu smxrcv wmtsecha
5325 52a851a8 44de56e8 1 sleeping secs:
1 9cpu smxRecvSnd
The problem requires the HDR pair to be initialized with a
specific order of steps that I have included as
an attachment with primary and secondary onconfig files.
In short, however, the steps go like this:
1 - on primary, oninit -iy
2 - on primary, onmode -d primary wmtsecha
3 - on primary, ontape -s -L 0
4 - on secondary, ontape -p
5 - on secondary, onmode -d secondary wmtpri
6 - on secondary, onmode -wf HA_ALIAS=wmtsecha
7 - on primary, onmode -x -2 wmtsec
At this point, any call on the primary to
dr_isSecondaryInCheckpoint will create an additional smx pipe. |
When this problem has been identified, you can bounce the
primary as a workaround. After the primary
is bounced, the primary will create an smx pipe for
dr_isSecondaryInCheckpoint, but it will reuse it for
any additional calls. |
