CA Service Management

In my SD v17.1 AA environment, occasionally I get a series of these errors in the stdlog on one of my app devices that eventually lead me to have to recycle that app device to restore my environment back to normal:

05/20 00:03:49.52 USMLVV1SDC spelsrvr 3236 ERROR chgwf.spl 1988 Error creating ITPAM workflow (/MS_ProcessHouse/Corp/Released/Flows/CWx-RunDetachUIMTicketproV17): ; nested exception is: java.net.SocketException: Connection reset by peer: socket write error
05/20 00:03:49.52 USMLVV1SDC spelsrvr 3236 ERROR pcat.spl 1535 Error starting ITPAM workflow (id=400624): ; nested exception is: java.net.SocketException: Connection reset by peer: socket write error

ITPAM doesn't seem to be the issue, as it has been shown to be receptive to "start workflow" calls from other outside sources, plus the other SD app server doesn't seem to be having any issues.  Once I recycle the SD service on the the app device taht is logging these errors, everything is back to normal.  Has anyone ever experienced this error before, and if so, what did you do to resolve the issue?  Thanks!

How often do you seem to be getting these types of messages? The timeout message indicates that it's taking longer than expected for Service Desk to get the response from Process Automation. Since Process Automation appears to be working just fine, it may indicate a problem related to the connectivity from the Service Desk server to the ITPAM server. Is there a possibility that there is a lose in connection between the servers, by any chance?

Ruling that out, a Support case may be needed for further investigation.

This has been happening recently like every few days.  And what’s interesting is that as soon as I recycle the SD service on the SD device that is logging these errors, the problem is fixed, which is why I was thinking the problem was more internal to the failing app device itself and not anything external to it.

I agree, it seems like something is getting hung up in the application. I was wondering if there was a possibility of something in the network causing a block that SDM just wasn't able to recover from. Going through a Support case is likely your best option at this time.

Thanks Alexander.  I will open up a case with CA.