CA Service Management

 View Only

AHD05949 Unable to acquire a repository session file not uploaded 

Sep 08, 2015 02:12 PM

01. Repository don't exists

     Solution: Administration > Attachments Library > Repositories

     Know more: How to Set Up the Attachments Library - CA Service Management - 14.1 - CA Technologies Documentation

 

02.  Is it everything OK with tomcat ?

Try: http://localhost:8080/CAisd/UploadServlet

See more on troubleshooting section

 

03. DNS Errors

CA SDM custom changes can be turn to different names, sometimes or somewhere can be access deny or don't answer for named server.

example: Workstation without domain

See more on troubleshooting section   

 

04. Restart Services/Windows

Experience: Could solved this problem just only restart Windows.

 

 

Troubleshooting Guidelines - from: Attachments - Best Practice Recommendations from Support

Trouble-shooting in Attachments typically involves double-checking installation settings.

The following guidelines have been developed by CA Support based on many issues received.

  1. Define the problem and be very specific, for example:

    • Did Attachments ever work? What changed?

    • What users and which browsers are affected?

    • If this does not impact all users, what is the location of the users that are not impacted?

    • Are all Service Desk Access Types/Roles impacted? eg Customer, Employee, Analyst

    • Do all Document repositories fail, or do attachments only fail on specific Document Repositories?

  2. Is Tomcat running? Better yet, is Tomcat Running on the same host specified in the Document Repository Detail Window/s?

    Try to backup the file /log/pdm_tomcat.log before recycling Tomcat, as it is overwritten on a recycle.

  3. Review the networking basics:

    • Ping

    • netstat /a

    • netstat /b (If on Windows 2003)

    • nslookup

    • hostname

  4. Obtain a screen shot of the problematic Document Repository and also of one that does not show problems if possible. Compare the settings.

  5. Does the "Server Name" field in the Document Repository Detail use a Fully qualified domain name?
    It should be set to the same as the value for NX_SERVER or NX_LOCAL_HOST (If a secondary).

  6. Case sensitivity of these names is an important matter and can be the sole cause of failure. For example, setting up the Repository to use 'myservr' rather than 'MyServ.'

  7. For trouble-shooting, always gather the following. If they do not reveal the problem on first analysis, they will be of use to the engineers who come after.

    Note that the 'Service Desk and CMDB Support Diagnostic Tool' can gather most of this information, with the exception of the pdm_extracts mentioned. See TEC469212.

    NX_ROOT/log
    NX_ROOT/<servername>.his file
    NX_ROOT/bopcfg/www/CATALINA_BASE/logs
    NX_ROOT/bopcfg/www/CATALINA_BASE/webapps/CAisd/WEB-INF/web.xml
    NX_ROOT/bopcfg/www/CATALINA_BASE/conf/server.xml
    NX_ROOT/pdmconf
    slstat > slstat.txt
    pdm_status > pdm_status.txt
    pdm_extracts of the following two tables:

    pdm_extract attmnt_folder >> attmnt.txt
    pdm_extract Document_Repository >> Document_Repository.txt

  8. If a recycle is possible and nothing else is revealed elsewhere, enable debug logging in log4j.properties under:

    NX_ROOT/bopcfg/www/CATALINA_BASE/webapps/CAisd/WEB-INF/log4j.properties

    Change this:
    log4j.rootCategory=info, jsrvrlog
    to:
    log4j.rootCategory=debug, jsrvrlog

    and recycle Service Desk. Then attempt to replicate the problem if possible.

    Note: Reading debug files correctly can be a time consuming process. Try more direct, obvious approaches first.

  9. Enabling pdm_trace or bop_logging on the appropriate webengine may be helpful as well.

    First identify the webengine, the user is connected to. Next, run slstat to find the slump process name for that webengine.  Last, run one of the following:

    pdm_trace web:local ON

    or

    bop_logging web:local ON

    Reproduce the problem, then turn off the trace:

    pdm_trace web:local OFF

    or

    bop_logging web:local OFF

    The traces will be written to NX_ROOT/log.

    You may wish to engage CA Support if the problem has not yielded to regular trouble-shooting at this point.

 

Attachments - Best Practice Recommendations from Support

AHD05949 Search Results

TEC484107

Statistics
0 Favorited
9 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Comments

Sep 10, 2015 02:30 PM

I recently received this error.

The system admin did the upgrade  of the windows server and after that i restored the system, so all returned to normal.

Related Entries and Links

No Related Resource entered.