CA Service Management

 View Only
  • 1.  Delayed Server Response Error When Changing Ticket Status

    Posted Aug 14, 2019 04:05 PM
      |   view attached
    Recently my DBA updated our DEV environment with PROD data and now we are receiving an error (Delayed Server Response) when trying to change the status of a current ticket or creating a new ticket.

    I am able to do the following without any error:
    • change category of current ticket
    • log comment to current ticket
    • change other fields (urgency, impact, group, assignee) of current ticket

    The error ONLY occurs when I try to change the ticket status or create a new ticket
    This is ONLY happening in our DEV environment, our test and production systems are working fine
    This ONLY started happening after the DEV environment was updated with PROD data
    I have checked (compared DEV to test and prod) all of the form files, nx.env and web.cfg files but found nothing out of the ordinary.


    Any help on what else I can look at or try to figure out what is happening.


    thank you
    TheKatherine

    ------------------------------
    System Technologist
    Sheetz Inc
    ------------------------------


  • 2.  RE: Delayed Server Response Error When Changing Ticket Status
    Best Answer

    Broadcom Employee
    Posted Aug 15, 2019 02:52 AM
    Edited by Christopher Hackett Aug 19, 2019 12:25 PM
    Hello Katherine,

    "Delayed Server Response" messages can be tricky to debug. At face value, they tell you that something is taking a long time to execute and there there is a bit of detective work to find out what and where that is.

    I shouldn't without getting further evidence, but I'm going to take a stab as the root cause, based the symptoms you described.  As it is localised to after a database restore, to a particular server instance (But not the production where maybe it was copied from) and only happens in very specific places, AND happens consistently in those places . . . then maybe there is a bad or missing index on the database? I've no idea why as database moves are usually an "all or nothing" affair, but it seems consistent with that.


    Failing that, here are some suggestions to get to the root cause of this.


    1) Check the SDM stdlogs for "delayed server response" or "zombie" messages that are matched in timestamp to what the client sees. Also large "milliseconds" messages.

    2) Ask your DBA to monitor what happens when you do the same action (Change Status for example) on both the prod. and dev.  They are either going to see a different query being generated (In which case, why? What is different between prod and dev?) Or else they are going to see the same query but it will execute differently.

    3) You could put on Fiddler to see what happens when the action is done on both prod and dev. Maybe something different is passed?

    4) Are you sure that the Dev. server has the same settings as the production server? You may well have copied the database identically . . . but what about the rest of the environment? Is the CA SDM configured with the same variables for example? There is an EXPECTED_WEB_RESPONSE variable that may have been bumped up in the application on the production system that didn't make it over to the dev. system. 
    https://docops.ca.com/ca-service-management/17-2/en/troubleshooting/troubleshooting-ca-service-desk-manager/how-to-extend-or-disable-the-delayed-server-response-timeout-in-ca-sdm
    Or maybe the dev. system is "underpowered" in some way? In which case you'd need to apply general performance troubleshooting (and you'd expect it to be occuring in more places than consistently and only in one section).

    Thanks, Kyle_R.

    EDIT.
    Also see these as they illustrate some of the troubleshooting mentioned above:
    Wolken | Internal
    Wolkenservicedesk remove preview
    Wolken | Internal
    View this on Wolkenservicedesk >



    Wolken | Internal
    Wolkenservicedesk remove preview
    Wolken | Internal
    View this on Wolkenservicedesk >
    https://ca-broadcomcsm.wolkenservicedesk.com/wolken/esd/knowledgebase_search?articleId=125291










  • 3.  RE: Delayed Server Response Error When Changing Ticket Status

    Posted Aug 15, 2019 03:59 PM

    This is a pretty common occurrence for us.  Given that it's a Development environment we often times modify the schema to support initiatives.  Laying on a different database but not cleaning up the application will result in the behavior you've described.  As mentioned the STD logs should tell you.  We utilize SQL and the error message gives a SQL error pinpointing the offending attribute(s).  You can then either roll back the changes, using https://ca-broadcom.wolkenservicedesk.com/external/article?articleId=27576  AND removing any custom forms that would utilize those fields so Dev mirrors Prod, or try to reintroduce the custom field back into your Dev environment, which honestly can be a drag.  Sometimes you can get lucky and go back into Schema Designer and add a description to a field and publish that to re-propagate the changes but more often than not I end up reverting everything so it matches Production then reintroducing the fields all over again.


    Derek~


  • 4.  RE: Delayed Server Response Error When Changing Ticket Status

    Broadcom Employee
    Posted Aug 15, 2019 08:48 PM
    Good points, Derek.

    Yes, customisations as well in case there are files left over - good call.

    The Swing Box method can be used to replicate a production server (It's not just for upgrades), or else a clean install and Swing Box. This ensures everything correctly matches across.

    https://docops.ca.com/ca-service-management/17-2/en/upgrading/upgrade-to-ca-service-management-17-2/upgrading-to-ca-service-desk-manager-17-2/use-the-swing-box-method-to-upgrade-to-ca-sdm-17-2

    Thanks, Kyle_R.


  • 5.  RE: Delayed Server Response Error When Changing Ticket Status

    Posted Aug 16, 2019 01:57 PM
    Thanks Derek and Kyle,

    Yes too many possibilities as to what is going wrong so we have decided to roll back our DEV environment to its original state before the production data was moved into it and then I will double check to be sure all customizations are in DEV, TEST and PROD environments ... once that is done, we will try to populate the DEV environment with PROD data again and go from there.


    thank you
    TheKatherine

    ------------------------------
    System Technologist
    Sheetz Inc
    ------------------------------