Hi LoneWanderer04,
If the problem persists, could you please contact the Support team via the Contact Support form and explain the issue in detail?
I'll try to clarify as much as I can.
We have a test suite where all the REST calls are done via NTLM.
The current issue I'm encountering is if I execute an API call, every other run gives me the error I listed. Nothing changes between attempts, other then I'll get a success, then "Remote host terminated the handshake" then success, then "Remote host terminated the handshake".
The two scenarios I've tried is running each call individually which does the above behavior, and running all the calls together in a full suite of tests, at which point the first API call in the suite gets that error.
Example:
1st run: POST *endpoint 1* - Success, I get a JSON package returned.
2nd run: POST *endpoint 1* - failure Error getting response; javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
3rd run: POST *endpoint 1* - Success, json package from 1st run returned
4th run: POST *endpoint 1* - failure Error getting response; javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
I don't think this is anything to do with ReadyAPI!/SoapUI at all.
To prove this - check the contents of the RAW request - one that is successful and one that fails - I'm betting they are identical.
Considering it fails on every other request, it sounds like the endpoint you're hitting has some rate limiting/SLA that doesn't allow a certain number of requests within a specific timeframe or something like that.
Have you tried inserting a Delay in between steps?
The answer (depending on the level of logging) will probably be reflected in the logs of the app server endpoint you are hitting.
ta
rich
Its a good thought, but that was one of the first things I checked, the Raws of the calls are the same, but it has nothing to do with delays from what I've seen. I've waited upwards of multiple minutes between calls, as long as the last call was a failure due to handshakes, the next call will succeed.
The more odd detail is if I run all the API calls together in a suite, only the first call in the suite will get the handshake error, the rest will all succeed even though a lot of them of being called one after the other in quick succession, further putting the timer idea as not being the main problem. I'll reach out to the server guys to see if there is anything on the logs, but they were telling me that they think it's on ReadyAPI's side since they weren't seeing anything the other day.
From what I can tell, the response just doesn't even go out when that happens, since the handshake fails right away, so it makes sense the server didn't have anything in depth.
Hey LoneWanderer04
Typically whenever the session is terminated more often than not it's something to do with the server/endpoint - not ReadyAPI!/SoapUI. The people responsible for the endpoint are always going to default to "it's your problem, not mine" cos that's standard software dev
The way to prove this one way or another is to use Fiddler.
submit 2 requests from ReadyAPI! using Fiddler to proxy the requests/responses to capture the details.
Do a straight comparison of a successful request and an unsuccessful one in which the session is terminated.
If the RAW details for the requests are identical (i.e. same headers and payload), then the issue isn't ReadyAPI!, it's your endpoint. If there are differences you need to identify what the differences are and fix them, but at this point I'm betting on identical and if that's the case, logic dictates it's your endpoint.
nice one
rich
So been continuing to look at this. The server configuration is going through a Load Balancer on the specific server I run the tests against.
We shut off one of the nodes completely and that seems to make it pass, so later today we are going to look into the Load Balancer configuration, since it appears that something is up with having calls go through multiple nodes.
UPDATE:
It appears to be due to the fact that the two main servers we use are configured with SNI. According to https://stackoverflow.com/questions/31245378/ssl-request-fails-from-soap-ui-works-with-fiddler-proxy, this seems to be due to ReadyAPI's Apache HttpClient 4.1.1 still not supporting that behavior (at least according to everything we've checked).
My question evolves to the following:
Does anybody know a way of overwriting Java in ReadyAPI so I manually overwrite the SNI to what I need?
SNIHostName
