sending notification to AlarmPoint via webservices - getting Read timed out

Hi all,

we use triggers to call javascripts to send new ticket notificaiton through AlarmPoint.  I send XML to AP (addEvent) using "doHTTPRequest", AP responds with an acknowledgement, and AP sends the emails to the oncall rotations.  If it's high severity ticket, the oncall has to acknowledge the AP notification, which updates/assigns the IM.  Everything works fine MOST of the time.

We are having internittent problems where I get the following response in the ticket activity log:

addEvent::AlarmPoint: Failed injecting event - Error calling method: doHttpRequest in class: com/hp/ov/sm/server/utility/HttpClient Exception ( Read timed out)

This doesnt happen often, but when it does, it disrupts the response turnaround, especially on higher severity tickets (they have to be acknowledged in a certain time to meet SLA's).  It happened last on 9/19 between 08:00 and 10:00 AM, then it cleared up and hasnt happened since.  It also appears that the notifications will ultimately go out, just delayed.  There is no intervention done on the Service Manager side.

Has anyone seen this?  The AlarmPoint SME is telling me it's a Service Manager issue.  I'm saying it's an AP issue, that the SM is doing what it's supposed to:  doHTTPRequest is sent, and it's timing out on the AP side.

Can anyone advise on how to resolve this?  or how to capture more info then just the failure message I'm getting now?  Do I just need to expand my Read Timeout (it's currently 10 seconds)?


  • Read time out is a very clear error :); You sent the request and didn't receive any response within the 10 seconds of timeout.

    Increase the value to a very high value like 60 seconds (it's a method parameter) and start to measure the response time for each one. With this data you will have more data to talk with the AP SME.

    You can also add to msglog/log the exactly request you are sending and the time and if he really want to solve the problem he can cross this information with their side monitoring (cpu, memory, network and application log); Probably he is able to see when he receive the request and when he provided the response.

    That said, the best would be have this integration on SMIS; by doing this you don't need to control by yourself the retry and expiration mechanism and you can set special actions in case of failure and retries expiration.