While doing a test in gatling I get the following error
java.io.IOException: Remotely closed
which is expected (server cuts connection). How do I mark the test success or check for that exception?
This exception means that the server closed the connection when the client (Gatling) was trying to write on it.
This might be in indication that you have to tune your keep-alive timeout to NOT match typical user think time, but such event will always happen.
But then, web browsers retry sending the request in case of such a failure.
Gatling can do that too, but it's disabled for now (will be enabled by default in 2.1.6). Until then, you can change the maxRetry value in gatling.conf.
Related
I have a Vert.x app that gets HTTP requests as a Server and later down the road sends the data (HTTP request as well) as a Client to several other servers (more than one Client exits).
I see in the logs that sometimes I get io.vertx.core.VertxException: Connection was closed
but with no other info.
How can I know which connection was the one that was actually closed? I have more than one connections active.
I tried to add exceptionHandler to HttpServer and to HttpClientRequest, but they both were never called.
The io.vertx.core.VertxException: Connection was closed can be triggered for both client connections and server connections.
You'd get these errors on your HTTP client connection if the remote server closed the connection before completing the response, and you'd be able to capture them by setting the appropriate handlers on the client request (With Vert.x 4, you'd do something like ...send().onFailure(err -> /* handle the failure */) ), which I believe you already do.
You'd get these errors for the HTTP server connection if the remote client disconnects, either before your server completed the response, or - if the connection has keep-alive enabled (which is the default for HTTP/1.1 connections) - even after the response was sent.
In case the client closed the server connection before the response was fully sent, you should be able to capture and handle there errors in the HttpServer.exceptionHandler(), as I'm sure you already do.
In case the client closed the server connection after the response was fully sent, while it is in a keep-alive state, then there is no HttpServerRequest (or RoutingContext if you are using vertx-web, as you should) where the exception happens in, so Vert.x would just disregard the error (see here for the code).
So why do you still see those errors in the log? It could be various things because that exception is also used to handle EventBus connections and all kinds of internal network streams managed by Vert.x servers - and all without a stack trace (the actual exception instance being thrown is created statically here), so Vert.x kinds of sucks in that way.
My recommendation: make sure you attach error handlers to everything (pay attention to websocket connections or HTTP response streams, if you use them) and if you still get those errors in the logs - maybe you can just ignroe them as the commenter suggested.
I am using the wrk HTTP benchmarking tool to test a server. And I am getting READ, WRITE as well as CONNECTION and TIMEOUT errors.
What I understand is:
CONNECTION errors, are caused by the refusal of a TCP connection.
Which could involve every element in the connection chain (Client,
ISP and Server).
TIMEOUT errors, are caused by the host failing to respond to a
request within a certain time.
But what about READ and WRITE errors?
I would really appreciate, if someone could point me in the direction of a good resource?
So what I understood from this code from the WRK repository is that.
WRITE ERROR’s happen when attempting to write on a connection, but it fails because of a closed socket on the server.
READ ERROR’s happen when attempting to read on a connection, but it fails because of a closed socket on the server.
Happy if anybody can confirm or refute that.
I am implementing a heartbeat endpoint/route using play 2.2.1 built with Scala 2.10.2 (running Java 1.7.0_45). When
the heartbeat endpoint is called, I want the controller to make http calls to localhost. If all of those
calls are ok, then the heartbeat endpoint will return an OK http response.
When I execute the following url from curl, I get the expected 200 response:
http://localhost:9000/oauth2/token. I am also able to telnet to localhost 9000.
I am also able to use WS successfully with an external URL:
WS.url("http://www.example.com").withHeaders("Content-Type" -> "application/json").get()
However, when I execute it from within my play app, I get a 500 tcp_error response.
WS.url("http://localhost:9000/oauth2/token").withHeaders("Content-Type" -> "application/json").get()
WS.url("http://127.0.0.1:9000/oauth2/token").withHeaders("Content-Type" -> "application/json").get()
WS.url("http://HostName:9000/oauth2/token").withHeaders("Content-Type" -> "application/json").get()
Here is the exact error message I receive:
Network Error (tcp_error)
A communication error occurred: "Connection refused"
The Web Server may be down, too busy, or experiencing other problems preventing it from responding to requests. You may wish to try again at a later time.
For assistance, contact your network support team.
Do I need to configure something to allow a play application to make calls to itself? Is this a network problem on
my box? If so, why do curl and telnet work? If a network issue, then it must be a jvm specific networking issue?
Could it be a security problem with play calling to itself? Not sure where to go next.
So I have a Perl script on a server. (Linux...). The script takes about 3+ minutes to fully complete, (this is normal for my script). Although the server keeps disconnecting, and my browser says that the server is not responding (it timed out I guess). How can I keep the connection alive for over 3+ minutes? (The client is just waiting for a response from the server. Nothing else on the client side is happening)...
Is this even possible?
If the server is closing the connection, you need to increase the server (Apache?) script timeout, which will be a parameter to mod_cgi or mod_cgid (depending on which one you're using). If you cannot change the Apache configuration then you might experiment with sending an innocuous HTTP header (i.e. Connection: keepalive, which is the default anyway) immediately before starting your processing. This will probably be sufficient to cause Apache not to give up waiting.
My client app gets intermittent winsock errors (10060, 10053) against one particular server we interface with. I have it re-trying the request that failed, but sometimes it fails repeatedly, and I give up after 5 re-tries. Would it be likely to help at all if I closed the socket and created a new one? (I know nothing about the server-side.)
Ok, so the errors that you're getting are:
10060 - WSAETIMEDOUT
10053 - WSAECONNABORTED
When do you get them? What are you doing at the time?
You get a WSAECONNABORTED when the remote end of the connection, or possibly an intermediary router, resets the connection and sends an RST. This could simply be the remote end issuing a non lingering close or it could be the remote end aborting or crashing.
You can't continue doing anything with a connection that has had a WSAECONNABORTED on it as the connection has been aborted and is no more; it is a dead connection, it has passed on...
Context matters immensely as to why you might get a WSAETIMEDOUT exception and the context will dictate if retrying is sensible or not.
One thing I would try is- do tracert to your server.
Often when someone is connected through VPN; you may see this error because your local and remote ip addresses overlap.
e.g. if your local ipaddress range is 192.168.1.xxx and vpn remote range is also 192.168.1.xxx you will also see this error.
sharrajesh