User guide

C-81
Cisco Media Gateway Manager 5.0 User Guide
OL-5461-02
Appendix C Troubleshooting
Connection Management Problems
Defect Information:
• stack trace of the sdbroker process "pstack <pid of sdbroker>"
• sdbroker and cmgrd logs.
Possible alternative workaround—None.
C.9.4.2.2 Cmgrd—Sdbroker Addition/Modification/Deletion Errors. Provisioning a Connection Results in an Error "sDatabroker
process busy. Please retry"
Related key index entries: cmgrd, sdbroker
The return error window on the screen states "sDatabroker process busy. Please retry". This indicates
that the CMGRD was able to process the request and send it to the sDbroker, but the sDbroker did not
respond prior to the CMGRD'S request time-out. Communication between the CMGRD and sDbroker
appear to be working though.
We need to determine if the sDbkr is "sleeping" or is overburdened with requests.
Step 1 Determine the sdbroker that should be processing the request. Use /opt/svplus/tools/dbcmap command.
Step 2 Check the message log to see if sDbkr is processing lots of other messages during the provisioning time
frame. If the message log is unavailable, check the shared memory between EM and DMD. ('count'
command). The column EMQDepth and Em R show current status of this shared memory. This will
show the sdbroker's processing at the present time not when the provisioning request failed. If there is a
large number of entries in the message log file, or the EM is pumping lots of messages to DMD, the
sDbroker is truly busy and the operator should wait for the system to catch up with current alarm events.
Defect Information:
• If the sdbroker is processing many traps (> 20/second) during the time of the provisioning request
then there is no sDbkr defect. Investigate the switch / NTS / EM if you feel that there should not be
this large number of requests occurring at the given time.
• If the sDbroker appears to be "sleeping" we need to capture the current status of the sDbkr. Execute
the "pstack <pid> " command twice and save the output.
Possible alternative workaround:
Repeated attempts at provisioning should be made. If there is a switch that is sending out many alarms,
fixing the problem on the switch is the best solution. If the sdbroker has been 'sleeping' for a long period
of time, then it should be killed and restarted.