What causes "Zombie" Connection messages in the CA Service Desk Manager (ITSM) STDLOGs?
search cancel

What causes "Zombie" Connection messages in the CA Service Desk Manager (ITSM) STDLOGs?

book

Article ID: 31656

calendar_today

Updated On:

Products

CA Service Desk Manager CA Service Management - Service Desk Manager ServiceDesk

Issue/Introduction

"Zombie connection" messages may appear in the CA Service Desk Manager (SDM/ITSM) stdlogs:

SEVERE_ERROR session.c 4268 Multiple responses received by zombie connection ## (0x03BE4600) for session cnt:###########################-##########:0x######

The above message may be associated with other stdlog entries such as:

SEVERE_ERROR session.c 10188 Attempt to change id of active Session <userid>:0x2900ce0 from ######## to ########

SIGNIFICANT session.c 3990 This request took 4222693 milliseconds to complete. session id:0 login name:<userid> htmpl name:delayed_server_response.htmpl

Environment

All versions of CA SDM and ITSM from CA SDM 14.1/17.x

Cause

When the webengine encounters a delayed backend response, it will advise the end user with the delayed server response form. 

It then saves the web connection as a "zombie" connection. 

Once a delayed response returns from the backend, the "zombie" connection is revived and readied to display output to the end user.

There could be an underlying performance issue contributing to these messages.

Resolution

Performance tuning is recommended to establish the extent of the issue.

For example, if the issue only occurs once, and is associated with a large known period of user activity - such as an end of year cycle - then isolated occurrences of this message may be deemed acceptable.

If the messages though are frequent, and/or are associated with other symptoms of poor performance, such as long delays when working with the web client, the performance analysis and tuning is recommended.

STEPS

1) Examine the extent of the issue. Review the stdlogs with a tool such as "Notepad++", search for "zombie" messages against all of the logs and see the frequency and scale of the issue.

2) Examine the logs and user experience for other signs of performance issues. For example, lots of long running "milliseconds" queries in the stdlogs.

3) Perform performance troubleshooting and an architecture review for matching business requirements of the system, against the installed environment. See documentation below.

Try to isolate the performance issue to a major area first, such as, "Is the performance being worst impacted by the . . .:"

  • Network
  • Database
  • Hardware
  • Application - configuration and customisations
  • Other environment (Firewalls, Anti-virus, authentication chain etc).

4) If needed, increase the timeout of the web client. This is usually recommended as a step after the above steps, as you should not mask a genuine performance issue by simple extending waiting periods, if the root cause is not known. 

On the other hand, it may be necessary to increase this variable before completing a full review, (a) if performance is severely impacted and an immediate workaround is required or (b) there are known architectural obstacles that cannot be overcome easily, such as a WAN with very long latency to remote sites. 

The delay threshold is 20 seconds and may be increased in the NX.ENV variable per Article Id: 30462 below, to a value such as "60."

Additional Information