My best guess would be to upgrade your server to SP4 and see if it helps, or to open a ticket with BMC under your support contract and see if they can get you some troubleshooting steps to try to get this resolved.
we have seen this too on one of our test systems, but not on another one. Not certain yet, but i suspect that the arsystem is crashing at some point and it looks like the armonitor restart doesn't have jetty in the command. So it works fine from a manual restart, but isn't restarting from an armonitor command.
The problem with that thought is that the Jetty server is embedded in the AR Server java process, so it's not possible for it to stay up when the process starts....I'm certainly not on the server team but I'm not familiar with anything that would cause the jetty server to stop responding by a remedy server restart...but logs could show if there was a server restart in the middle of things.
We have the same situation, or close in only our dev environment and we are on 9.1.03 patch 1. Just started happening this weekend, and nothing in the logs etc, we are still troubleshooting what happens to Jetty but ar server is still alive, however, in our situation the load balancer cannot connect to either port, tcp or ssl 443 for jetty.
Following this discussion
Any updates from anybody on this issue?
We finally solved the issue, after contacting BMC support, the SME saided that the problem was in the consume of the REST API, we where passing the params directly with the URL, like user and password, the solution is to pass the parameters always in the request body.
So BMC is saying to put the parameters of the GET request in the body instead of in the URL?
A normal GET request could look like
our problem is resolved now. Initially we were trying to use operations encoded in the url-parameters as you suggested. This however resulted in Jetty not answering our requests at all. No Error-Message, no log entry, nothing. Then I stumbled upon this post and read Jerrys answer where he stated that
"the solution is to pass the parameters always in the request body"
So since the docs (Operations on entry objects - Documentation for BMC Remedy Action Request System 9.1 - BMC Documentation ) don't explicitly say otherwise, we were assuming that this might be the way to go. Hence my post, criticizing that this might not be the best idea of handling GET-Requests.
However, after some more searching in the community, I found this post :REST API fields parameter in which people found out that Postman seems to be the culprit here. Basically, when you send a GET-Request via Postman under Windows, chances are that Postman somehow escapes characters in a way that the REST API cant handle, resulting in dropping the response entirely.
It would be great to see a patch that replaces the dropped response with a status 400.