I'm getting the issue read ip1->ip2 read: connection reset by peer testing an App locally in my machine. I'm the only one facing this issue.
If I make ping over the first ip it responds ok.
With the second one ip2, I'm getting the issue:
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
....
I'm guessing that it is the cause of the issue. (What this two ip means? The ip1 and the ip2)
Is there any issue related with the mac or the security config?
Related
Below is the configured thread group
Thread Group
|
|--> HTTP SAMPLE
I am opening 5 threads in 5 seconds with loop count is 5. It means in each thread 5 HHTP request will be sent, so total 25 request.
Thread 1 : TCP CONNECTION OPENED --> HTTP REQUEST SENT ---> HTTP RESPONSE RECEIVED.
Question: After receiving response whether TCP connection will be closed and again TCP connection will be opened and then HTTP request will be sent?
Or once response is received in same TCP connection next HTTP request will be sent?
It depends on what do you set in the HTTP Request sampler, if you tick Use KeepAlive box - then JMeter will send Connection header with the value of keep-alive
it means that the underlying TCP connection will remain open and the next HTTP Request sampler(s) will be reusing this connection.
If you untick the box JMeter will send Connection header with the value of close and next HTTP Request sampler will re-establish the connection.
You need to check what's going on in reality using your browser developer tools or an external sniffer tool like Wireshark and configure JMeter to behave exactly like the real browser does
I am new to Mule and trying to learn Mule 3 (some of our existing API in production are using Mule 3).
A production application has an HTTPlistener using 'use Persistent connection' and 'connection idle timeout' as default value of 30000 (30 seconds).
My understanding i that if I call the API that listens to the request at this listener from Postman (the REST client), if the request takes more than 30 seconds, it should receive a timeOut error (504).
We added a Thread.sleep in an expression to simulate this behavior.
<expression-component doc:name="Expression"><![CDATA[Thread.sleep(60000);]]></expression-component>
This will cause the sleep to wait for 1 minute, which is greater than 30 seconds configured for a timeout.
However, the request waits for the thread to wake up after 1 minute and returns a successful response.
So I am not sure what is the purpose of 'connection idle timeout' ?
Also, what does 'persistent connection' mean ?
The documentation is vague.
HTTP Persistent Connections are a feature of the HTTP protocol, that the connector implements. The connection idle time indicates how long the persistent connection will remain open if there is no activity. It is not related to a response timeout, that is a timeout on the client side and seems to be what you are expecting. In this case the HTTP Listener is the server and Postman is the client.
A response timeout in the client doesn't has an HTTP status response because the request is aborted. You can get a 504 status if the request is against a proxy and the proxy has a client timeout against a backend. The proxy usually returns a 504 in that scenario.
The documentation for connectors assumes that you are familiar with the protocol or backend concepts. In this case the HTTP protocol.
On http persistent there is a "keep alive" timer.
When the keep alive time is over , what happend?
the tcp connection will close? i don't think so because there is keep alive on tcp connection that exsist.
so what is the affect of "keep alive http timer"?
If i open http connection to url (TCP) on port 80 ,
the port of server will not be free until the tcp connection will end.
so what if the http keep alive end?
I tried to understand that .
i will be happy if i get an official source to this .
thanks!
On http persistent there is a "keep alive" timer.
Correct. Don't confuse it with TCP keepalive, which is a completely different thing (RFC 1122). I am here assuming you are talking about HTTP as per your text.
When the keep alive time is over, what happened?
The connection will be closed by one peer or the other.
the tcp connection will close?
Correct.
I don't think so because there is keep alive on tcp connection that exist.
I don't know what this means.
so what is the affect of "keep alive http timer"?
It closes open HTTP connections when the specified period of inactivity has expired.
If i open http connection to url (TCP) on port 80 , the port of server will not be free until the tcp connection will end.
Incorrect. You can open many connections to the same listening port.
so what if the http keep alive end?
The connection is closed. You've already asked that.
I will be happy if I get an official source to this.
The official source for HTTP 1.1 is RFC 7230-5, the successors of RFC 2616.
TCP level keepalive is done out of band, so there is no stream data associated with this. This means applications using sockets don't see the effect of TCP keepalives, so an idle connection will still be closed by an http server or proxy.
Also, the interval for sending TCP keepalives is typically very long by default (hours). You can find more information on the keepalive socket option here on MSDN
HTTP doesn't allow a server to attempt to prompt a client to do something, so if the client doesn't use a connection, the only option is to close it or leave it open. That is typically a configuration option in the server or proxy.
Is there a way to keep idle connection open after a specified timeout at the server side?
I have a http server implemented using golang1.4 and an API will respond after 10 seconds. While I set MaxIdleConnsPerHost at the client (using golang1.4), I still get the read tcp xx.xx.xx.xx:xx: use of closed network connection. I think it may be caused by server closing the idle connection.
I found GOLANG, HTTP having “use of closed network connection” error and http.Server: timeout for idle connections only?, but they didn't help.
At the server side, set ReadTimeout may help.
Ref: Creating an idle timeout in Go?
I am running a backend server with gunicorn behind an nginx 1.6.2 on ubuntu 12.04.
Recently I noticed a lot of 408's in the nginx logs for upload (POST) requests and changing the various timeouts in nginx config I got to know that it was due to client_body_timeout.
Taking tcpDump on the server side it looked like the client is not sending anything after the initial SYN and SYNACK packets and after the client body timeout time the server tries to close the connection by sending FIN ACK, but the client does not ACK and the server goes into its retransmission policy.
Is there anything I am missing or any HTTP header needs to be added or any tcp parameter need to be configured
I found the issue.
Took the client side tcpdump n found that only small sized tcp segments were reaching the client.
Reduced mss to 1200 and it worked for me :). Don't know if this is the correct approach.