Re: TCP connections reuse
Hi Christopher, We actually found what was the problem with keep-alive. It is caused by the fact that Tomcat didn’t specify parameters ‘Keep-Alive: timeout=60,max=100’, in HTTP header. In this case Java uses parameters by default, ie ‘Keep-Alive: timeout=0,max=5’ and that is why connection been closed by the client immediately. Please advise if it is possible to configure tomcat to set in Http response header parameters ‘Keep-Alive: timeout=60,max=100’? Currently I’ve set parameters ‘keepAliveTimeout=6, maxKeepAliveRequests = 100’ for tomcat connector but response header still does not contain these values. BR, Maxim From: Christopher Schultz Reply-To: Tomcat Users List Date: Saturday 13 June 2015 02:17 To: Tomcat Users List Subject: Re: TCP connections reuse -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Andy, On 6/12/15 12:35 PM, Wang, Andy wrote: Could this be as simple as the default keepaliveTimeout = 2 (i.e. 20s) This could certainly be the issue. Maxim, what does the timing look like with these events? 1. First HTTP request made 2. Connection is dropped 3. Second HTTP request is made (on a new connection) When do those things happen? You said you had protocol traces of everything. If #2 happens 20 seconds after #1, then I think you have your answer. - -chris From: Andy Wang [aw...@ptc.com] Sent: Friday, June 12, 2015 11:31 AM To: Tomcat Users List Subject: Re: TCP connections reuse Could this be as simple as the default keepaliveTimeout = 15000 (i.e. 15s) Andy On 06/12/2015 11:20 AM, Christopher Schultz wrote: Maxim, On 6/12/15 1:53 AM, Maxim Neshcheret wrote: According to http://docs.oracle.com/javase/6/docs/technotes/guides/net/http-keep ali ve.html connections in HTTP 1.1 http://docs.oracle.com/javase/6/docs/technotes/guides/net/http-kee pal ive.html%20connections%20in%20HTTP%201.1 are persistent by default. But if it is incorrect behavior in Java then maybe there is some way or configuration in Tomcat to put Keep-alive parameter in the response header? I do call HttpURLConnection.disconnect() only when client is stopped. Keep-alive is used for sure. I would expect the connection to be kept open unless you call disconnect. But you are creating a new HttpURLConnection each time and then discarding it. I'm not sure how the connection pooling works under the hood within the JVM. It used to be difficult to get the JVM to release a connection and actually terminate the TCP/IP connection. http://docs.oracle.com/javase/8/docs/technotes/guides/net/http-keepali ve .html Pay close attention to the remarks about stream-handling. Tomcat may close the connection under certain circumstances, usually error-related. If you are getting 200 OK responses from Tomcat, then I'm not sure why the TCP/IP connection would be dropped, unless Java thinks that 30 seconds is too long of an idle time to keep those connections open. Thanks, -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVezA+AAoJEBzwKT+lPKRYV6QP/RvmRCvEdPszj9KriN6P+6ab B5sqrB5mlNtfxvyv8k33EtJf3l6h/tQDYE2eOCN4MvKRAGf7XdhA7udYxXUYBDRQ vhHPoUIhqP32RmQwEBnB3i47xASHDg1G1F7Ttqw6wL9p48APr5IlIs47Pr61en0n 11pHTt+25bGr36NgK0UlIIzJzEpH/HYikLS/wfqYNoVXn7RczkzKDrxg0xwZRgbg TacT4zz1noCaNPOqM1Jjdn+7Ilq+fPabhW8cOXPhkBU0RCE58HdwQ5Fu8BEPx5Sp 6qFmjtAEsTEGHHSin10/6GFA6EAypDQXRTulFQpq5eIZLNSl+l7EeFfE98n4Qyqj xrNeXKX06qdPO0gzjA0Q064vu2ZFSSIDFp6/zGtMqLhPhbPPTS5A6zpvXOJcfW28 k6b+mdOVGSiJ8zjz1NgsRtqtbwm1+y+Uh/UPdMDf7KhmS2EtxDtw4h8JYvKprkeQ Jwgh99Qu1a/hAmSRmRXjmlaC1RRXlMJcoHezHAicvRlwv0fko7/p5aqhK5nbogO+ aZV3GbaGmwWtp6JN2oCK4PdoQfgQS6nUYMmWoIHHSd1lTs8TQranG6M/bITNFinM vcUUZn6cqy6o+X4E/wz1x0CMiUoVlGIJeZevq65lhiaEXL3I2NMpeJtqpNP3cIof y4Cg/KPPs/B8TfnLM9WP =bGdd -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TCP connections reuse
On 16/06/2015 11:26, Maxim Neshcheret wrote: Hi Mark We are using HTTP/1.1. Then why are you expecting Tomcat to provide a Keep-alive header? That is not part of HTTP/1.1. Mark BR, Maxim From: Mark Thomas Reply-To: Tomcat Users List Date: Tuesday 16 June 2015 16:18 To: Tomcat Users List Subject: Re: TCP connections reuse On 16/06/2015 09:25, Maxim Neshcheret wrote: Hi Christopher, We actually found what was the problem with keep-alive. It is caused by the fact that Tomcat didn’t specify parameters ‘Keep-Alive: timeout=60,max=100’, in HTTP header. In this case Java uses parameters by default, ie ‘Keep-Alive: timeout=0,max=5’ and that is why connection been closed by the client immediately. Please advise if it is possible to configure tomcat to set in Http response header parameters ‘Keep-Alive: timeout=60,max=100’? Currently I’ve set parameters ‘keepAliveTimeout=6, maxKeepAliveRequests = 100’ for tomcat connector but response header still does not contain these values. That looks like the broken HTTP/1.0 keep-alive negotiation mentioned in RFC 2068. That isn't how keep-alive works in HTTP/1.1 Mart - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TCP connections reuse
On 16/06/2015 09:25, Maxim Neshcheret wrote: Hi Christopher, We actually found what was the problem with keep-alive. It is caused by the fact that Tomcat didn’t specify parameters ‘Keep-Alive: timeout=60,max=100’, in HTTP header. In this case Java uses parameters by default, ie ‘Keep-Alive: timeout=0,max=5’ and that is why connection been closed by the client immediately. Please advise if it is possible to configure tomcat to set in Http response header parameters ‘Keep-Alive: timeout=60,max=100’? Currently I’ve set parameters ‘keepAliveTimeout=6, maxKeepAliveRequests = 100’ for tomcat connector but response header still does not contain these values. That looks like the broken HTTP/1.0 keep-alive negotiation mentioned in RFC 2068. That isn't how keep-alive works in HTTP/1.1 Mart - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TCP connections reuse
Hi Mark We are using HTTP/1.1. BR, Maxim From: Mark Thomas Reply-To: Tomcat Users List Date: Tuesday 16 June 2015 16:18 To: Tomcat Users List Subject: Re: TCP connections reuse On 16/06/2015 09:25, Maxim Neshcheret wrote: Hi Christopher, We actually found what was the problem with keep-alive. It is caused by the fact that Tomcat didn’t specify parameters ‘Keep-Alive: timeout=60,max=100’, in HTTP header. In this case Java uses parameters by default, ie ‘Keep-Alive: timeout=0,max=5’ and that is why connection been closed by the client immediately. Please advise if it is possible to configure tomcat to set in Http response header parameters ‘Keep-Alive: timeout=60,max=100’? Currently I’ve set parameters ‘keepAliveTimeout=6, maxKeepAliveRequests = 100’ for tomcat connector but response header still does not contain these values. That looks like the broken HTTP/1.0 keep-alive negotiation mentioned in RFC 2068. That isn't how keep-alive works in HTTP/1.1 Mart - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TCP connections reuse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Andy, On 6/12/15 12:35 PM, Wang, Andy wrote: Could this be as simple as the default keepaliveTimeout = 2 (i.e. 20s) This could certainly be the issue. Maxim, what does the timing look like with these events? 1. First HTTP request made 2. Connection is dropped 3. Second HTTP request is made (on a new connection) When do those things happen? You said you had protocol traces of everything. If #2 happens 20 seconds after #1, then I think you have your answer. - -chris From: Andy Wang [aw...@ptc.com] Sent: Friday, June 12, 2015 11:31 AM To: Tomcat Users List Subject: Re: TCP connections reuse Could this be as simple as the default keepaliveTimeout = 15000 (i.e. 15s) Andy On 06/12/2015 11:20 AM, Christopher Schultz wrote: Maxim, On 6/12/15 1:53 AM, Maxim Neshcheret wrote: According to http://docs.oracle.com/javase/6/docs/technotes/guides/net/http-keep ali ve.html connections in HTTP 1.1 http://docs.oracle.com/javase/6/docs/technotes/guides/net/http-kee pal ive.html%20connections%20in%20HTTP%201.1 are persistent by default. But if it is incorrect behavior in Java then maybe there is some way or configuration in Tomcat to put Keep-alive parameter in the response header? I do call HttpURLConnection.disconnect() only when client is stopped. Keep-alive is used for sure. I would expect the connection to be kept open unless you call disconnect. But you are creating a new HttpURLConnection each time and then discarding it. I'm not sure how the connection pooling works under the hood within the JVM. It used to be difficult to get the JVM to release a connection and actually terminate the TCP/IP connection. http://docs.oracle.com/javase/8/docs/technotes/guides/net/http-keepali ve .html Pay close attention to the remarks about stream-handling. Tomcat may close the connection under certain circumstances, usually error-related. If you are getting 200 OK responses from Tomcat, then I'm not sure why the TCP/IP connection would be dropped, unless Java thinks that 30 seconds is too long of an idle time to keep those connections open. Thanks, -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVezA+AAoJEBzwKT+lPKRYV6QP/RvmRCvEdPszj9KriN6P+6ab B5sqrB5mlNtfxvyv8k33EtJf3l6h/tQDYE2eOCN4MvKRAGf7XdhA7udYxXUYBDRQ vhHPoUIhqP32RmQwEBnB3i47xASHDg1G1F7Ttqw6wL9p48APr5IlIs47Pr61en0n 11pHTt+25bGr36NgK0UlIIzJzEpH/HYikLS/wfqYNoVXn7RczkzKDrxg0xwZRgbg TacT4zz1noCaNPOqM1Jjdn+7Ilq+fPabhW8cOXPhkBU0RCE58HdwQ5Fu8BEPx5Sp 6qFmjtAEsTEGHHSin10/6GFA6EAypDQXRTulFQpq5eIZLNSl+l7EeFfE98n4Qyqj xrNeXKX06qdPO0gzjA0Q064vu2ZFSSIDFp6/zGtMqLhPhbPPTS5A6zpvXOJcfW28 k6b+mdOVGSiJ8zjz1NgsRtqtbwm1+y+Uh/UPdMDf7KhmS2EtxDtw4h8JYvKprkeQ Jwgh99Qu1a/hAmSRmRXjmlaC1RRXlMJcoHezHAicvRlwv0fko7/p5aqhK5nbogO+ aZV3GbaGmwWtp6JN2oCK4PdoQfgQS6nUYMmWoIHHSd1lTs8TQranG6M/bITNFinM vcUUZn6cqy6o+X4E/wz1x0CMiUoVlGIJeZevq65lhiaEXL3I2NMpeJtqpNP3cIof y4Cg/KPPs/B8TfnLM9WP =bGdd -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TCP connections reuse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Maxim, On 6/12/15 1:53 AM, Maxim Neshcheret wrote: According to http://docs.oracle.com/javase/6/docs/technotes/guides/net/http-keepali ve.html connections in HTTP 1.1 http://docs.oracle.com/javase/6/docs/technotes/guides/net/http-keepal ive.html%20connections%20in%20HTTP%201.1 are persistent by default. But if it is incorrect behavior in Java then maybe there is some way or configuration in Tomcat to put Keep-alive parameter in the response header? I do call HttpURLConnection.disconnect() only when client is stopped. Keep-alive is used for sure. I would expect the connection to be kept open unless you call disconnect. But you are creating a new HttpURLConnection each time and then discarding it. I'm not sure how the connection pooling works under the hood within the JVM. It used to be difficult to get the JVM to release a connection and actually terminate the TCP/IP connection. http://docs.oracle.com/javase/8/docs/technotes/guides/net/http-keepalive .html Pay close attention to the remarks about stream-handling. Tomcat may close the connection under certain circumstances, usually error-related. If you are getting 200 OK responses from Tomcat, then I'm not sure why the TCP/IP connection would be dropped, unless Java thinks that 30 seconds is too long of an idle time to keep those connections open. Thanks, - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVewa7AAoJEBzwKT+lPKRYke0QALlr4G7IZueNeG90NCsMhY4Y iU4RsiXDFRBgb3Wd9X305yyYiULzRB2u7TXAirB2vXttJiBmXR6v9cKqxW2DdgDZ cRRd+ymQbDyhhO3RDodVDQp8OAf3YlXoTH+zIvSYYFnzo148iuHxLyLrXyyHkfv2 wf5zwVjLVH0Pu7ndTbu23kJ6zhMKrOzzgKa1t/iWOa9LqxE6vht9d24HYzyluZoQ xnmkovYf2bNo4pVw4xcg9QNeeIDAnRBBcusNr4qUjif14pA7fmbliTPBtzFTyi9/ AuFlNdIJtz5zLXhTopjLwkrNDyx3AFwo0UQrlpoaoURAvVhDri5PlphDM94TyLBx VRPeChq1Tj0wnAP/j1wqr6VEyC30AZ/w/z89zwy1SpTE7ywUwmJmamFcSVoUTOjL U9J78+29pzlzcFj1OR0lh5xXMjL0yXmcLXSmKNWp0AwbVQacV5PSz5QqM32zM9Bn 1sOndI24BXcl3VyXPai9JdmxgoowGCszis+xCn+yuDwE5moeBV7xmeQtdagnhFex oBzGNDH/K/Up/Kh2bUxPXM0Ij0ksG6L8s8WTuyu1Tctly0NG5piW2xDwjs9nbomc qKQvfjnd5zI3ps6CyE/ZTa0LacyolaRgWVxXoZZ9En4bUVVexOHLllzc7e7uban4 C4Tgxbwn1lMQ8+GLYYrd =AbYE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TCP connections reuse
Could this be as simple as the default keepaliveTimeout = 15000 (i.e. 15s) Andy On 06/12/2015 11:20 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Maxim, On 6/12/15 1:53 AM, Maxim Neshcheret wrote: According to http://docs.oracle.com/javase/6/docs/technotes/guides/net/http-keepali ve.html connections in HTTP 1.1 http://docs.oracle.com/javase/6/docs/technotes/guides/net/http-keepal ive.html%20connections%20in%20HTTP%201.1 are persistent by default. But if it is incorrect behavior in Java then maybe there is some way or configuration in Tomcat to put Keep-alive parameter in the response header? I do call HttpURLConnection.disconnect() only when client is stopped. Keep-alive is used for sure. I would expect the connection to be kept open unless you call disconnect. But you are creating a new HttpURLConnection each time and then discarding it. I'm not sure how the connection pooling works under the hood within the JVM. It used to be difficult to get the JVM to release a connection and actually terminate the TCP/IP connection. http://docs.oracle.com/javase/8/docs/technotes/guides/net/http-keepalive .html Pay close attention to the remarks about stream-handling. Tomcat may close the connection under certain circumstances, usually error-related. If you are getting 200 OK responses from Tomcat, then I'm not sure why the TCP/IP connection would be dropped, unless Java thinks that 30 seconds is too long of an idle time to keep those connections open. Thanks, - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVewa7AAoJEBzwKT+lPKRYke0QALlr4G7IZueNeG90NCsMhY4Y iU4RsiXDFRBgb3Wd9X305yyYiULzRB2u7TXAirB2vXttJiBmXR6v9cKqxW2DdgDZ cRRd+ymQbDyhhO3RDodVDQp8OAf3YlXoTH+zIvSYYFnzo148iuHxLyLrXyyHkfv2 wf5zwVjLVH0Pu7ndTbu23kJ6zhMKrOzzgKa1t/iWOa9LqxE6vht9d24HYzyluZoQ xnmkovYf2bNo4pVw4xcg9QNeeIDAnRBBcusNr4qUjif14pA7fmbliTPBtzFTyi9/ AuFlNdIJtz5zLXhTopjLwkrNDyx3AFwo0UQrlpoaoURAvVhDri5PlphDM94TyLBx VRPeChq1Tj0wnAP/j1wqr6VEyC30AZ/w/z89zwy1SpTE7ywUwmJmamFcSVoUTOjL U9J78+29pzlzcFj1OR0lh5xXMjL0yXmcLXSmKNWp0AwbVQacV5PSz5QqM32zM9Bn 1sOndI24BXcl3VyXPai9JdmxgoowGCszis+xCn+yuDwE5moeBV7xmeQtdagnhFex oBzGNDH/K/Up/Kh2bUxPXM0Ij0ksG6L8s8WTuyu1Tctly0NG5piW2xDwjs9nbomc qKQvfjnd5zI3ps6CyE/ZTa0LacyolaRgWVxXoZZ9En4bUVVexOHLllzc7e7uban4 C4Tgxbwn1lMQ8+GLYYrd =AbYE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: TCP connections reuse
Sorry, correction: default keepalivetimeout = connectionTimeout = 2 (20s) Andy From: Andy Wang [aw...@ptc.com] Sent: Friday, June 12, 2015 11:31 AM To: Tomcat Users List Subject: Re: TCP connections reuse Could this be as simple as the default keepaliveTimeout = 15000 (i.e. 15s) Andy On 06/12/2015 11:20 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Maxim, On 6/12/15 1:53 AM, Maxim Neshcheret wrote: According to http://docs.oracle.com/javase/6/docs/technotes/guides/net/http-keepali ve.html connections in HTTP 1.1 http://docs.oracle.com/javase/6/docs/technotes/guides/net/http-keepal ive.html%20connections%20in%20HTTP%201.1 are persistent by default. But if it is incorrect behavior in Java then maybe there is some way or configuration in Tomcat to put Keep-alive parameter in the response header? I do call HttpURLConnection.disconnect() only when client is stopped. Keep-alive is used for sure. I would expect the connection to be kept open unless you call disconnect. But you are creating a new HttpURLConnection each time and then discarding it. I'm not sure how the connection pooling works under the hood within the JVM. It used to be difficult to get the JVM to release a connection and actually terminate the TCP/IP connection. http://docs.oracle.com/javase/8/docs/technotes/guides/net/http-keepalive .html Pay close attention to the remarks about stream-handling. Tomcat may close the connection under certain circumstances, usually error-related. If you are getting 200 OK responses from Tomcat, then I'm not sure why the TCP/IP connection would be dropped, unless Java thinks that 30 seconds is too long of an idle time to keep those connections open. Thanks, - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVewa7AAoJEBzwKT+lPKRYke0QALlr4G7IZueNeG90NCsMhY4Y iU4RsiXDFRBgb3Wd9X305yyYiULzRB2u7TXAirB2vXttJiBmXR6v9cKqxW2DdgDZ cRRd+ymQbDyhhO3RDodVDQp8OAf3YlXoTH+zIvSYYFnzo148iuHxLyLrXyyHkfv2 wf5zwVjLVH0Pu7ndTbu23kJ6zhMKrOzzgKa1t/iWOa9LqxE6vht9d24HYzyluZoQ xnmkovYf2bNo4pVw4xcg9QNeeIDAnRBBcusNr4qUjif14pA7fmbliTPBtzFTyi9/ AuFlNdIJtz5zLXhTopjLwkrNDyx3AFwo0UQrlpoaoURAvVhDri5PlphDM94TyLBx VRPeChq1Tj0wnAP/j1wqr6VEyC30AZ/w/z89zwy1SpTE7ywUwmJmamFcSVoUTOjL U9J78+29pzlzcFj1OR0lh5xXMjL0yXmcLXSmKNWp0AwbVQacV5PSz5QqM32zM9Bn 1sOndI24BXcl3VyXPai9JdmxgoowGCszis+xCn+yuDwE5moeBV7xmeQtdagnhFex oBzGNDH/K/Up/Kh2bUxPXM0Ij0ksG6L8s8WTuyu1Tctly0NG5piW2xDwjs9nbomc qKQvfjnd5zI3ps6CyE/ZTa0LacyolaRgWVxXoZZ9En4bUVVexOHLllzc7e7uban4 C4Tgxbwn1lMQ8+GLYYrd =AbYE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TCP connections reuse
From: Christopher Schultz
Reply-To: Tomcat Users List
Date: Thursday 11 June 2015 09:12
To: Tomcat Users List
Subject: Re: TCP connections reuse
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Maxim,
On 6/10/15 4:12 AM, Maxim Neshcheret wrote:
I have java http client which sends periodically (every 30 sec;
this code is run by heartbeat thread in the cycle) heartbeats
*private* PostResponse post(String jSessionCookie, *final* String
action, *final* String data, *final* *int* postTimeoutMs) *throws*
IOException, SSYSException
{
*final* HttpURLConnection httpConn = openHttpUrlConnection(*true*,
postTimeoutMs, jSessionCookie);
What does openHttpUrlConnection do?
This method simply gets new instance of HttpURLConnection
protected HttpURLConnection openHttpUrlConnection(final boolean isPost,
final int timeout, final String jSession) throws IOException {
final HttpURLConnection httpConn;
final String method;
httpConn = (HttpURLConnection) url.openConnection();
if (isPost) {
method = POST;
httpConn.setReadTimeout(timeout);
} else {
method = GET;
httpConn.setRequestProperty( Connection, Keep-Alive);
}
httpConn.setDoOutput(true);
httpConn.setRequestMethod(method);
httpConn.setRequestProperty(Content-Type,
application/x-www-form-urlencoded;charset= + DefaultProperty.httpEncoding);
if (jSession != null) {
httpConn.addRequestProperty(Cookie, jSession);
log.trace(JSession for + method + ' + jSession + ');
}
return httpConn;
}
*final* OutputStream os = httpConn.getOutputStream();
*try* (*final* PrintWriter wr = *new* PrintWriter(
DefaultProperty./isEnableSocketTraceGW/ ? *new*
TracerOutputStream(os) : os )) {
*final* String text = action= + action + data= +
URLEncoder./encode/(data, DefaultProperty./httpEncoding/);
You should encode the action String, too.
Yes, you are right. Thanks for notice
wr.write(text); wr.flush();
*final* *int* respCode = httpConn.getResponseCode();
*if* (respCode != HttpURLConnection.*/HTTP_OK/*)
{
String info = Incorrect response from server, responseCode: +
respCode + , message: + httpConn.getResponseMessage();
*/log/*.error(info);
*throw* *new* SSYSException(SSYSCoreEx.*/ERR_UNKNOWN_ERROR/*,
info);
}
}
*if* (jSessionCookie == *null*)
{
jSessionCookie = getJSessionCookie(httpConn);
}
*final* InputStream inputStream = httpConn.getInputStream();
*try* (*final* BufferedReader reader = *new* BufferedReader(*new*
InputStreamReader(
(DefaultProperty./isEnableSocketTraceGW/ ?
*new* TracerInputStream(inputStream)
:
inputStream
)
, DefaultProperty./httpEncoding/)))
You probably want to use the *actual* encoding of the response.
Yes, but on server side I have same property for response and both are
initialized with UTF-8 value. So should not be a problem here
{
*/log/*.trace(before readline(post));
String replyText = reader.readLine();
*/log/*.trace(after readline(post): [ + replyText + ]);
NReply nReply = PoolGson./fromJson/(replyText, NReply.*class*);
*if* (nReply == *null*) {
*final* String msg = corrupted reply, action: + action;
*/log/*.debug(msg);
*throw* *new* IOException(msg);
}
*return* *new* PostResponse(replyText, nReply, jSessionCookie,
nReply.id);
}
}
On the server side there is Tomcat 8.0.21 + APR connector.
Every time this heartbeat is sent I see in the Wireshark and
EtherDetect that new TCP connection is opened (SYN-SYNACK packets)
and after getting response from Tomcat connection is closed (FIN –
FINACK packets).
I was expecting that TCP connections will be reused but not closed.
Are you sending a Connection header to the server?
Is it problem in my client or it can be solved by Java and/or
Tocmat configuration?
That depends. IIRC, HttpURLConnection used to use KeepAlive *by
default* but that turned out to be a surprise to a lot of people and
caused resource issues. I'm not sure if Sun/Oracle changed their minds
about that and changed the default to be Connection: close.
According to
http://docs.oracle.com/javase/6/docs/technotes/guides/net/http-keepalive.html
connections in HTTP 1.1 are persistent by default.
But if it is incorrect behavior in Java then maybe there is some way or
configuration in Tomcat to put Keep-alive parameter in the response header?
I notice that you are *not* calling HttpURLConnection.disconnect(),
which is probably the correct decision given what you'd like to do.
I'd confirm that Connection: keep-alive is being used with your
connection, just in case.
I do call HttpURLConnection.disconnect() only when client
Re: TCP connections reuse
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Maxim,
On 6/10/15 4:12 AM, Maxim Neshcheret wrote:
I have java http client which sends periodically (every 30 sec;
this code is run by heartbeat thread in the cycle) heartbeats
*private* PostResponse post(String jSessionCookie, *final* String
action, *final* String data, *final* *int* postTimeoutMs) *throws*
IOException, SSYSException
{
*final* HttpURLConnection httpConn = openHttpUrlConnection(*true*,
postTimeoutMs, jSessionCookie);
What does openHttpUrlConnection do?
*final* OutputStream os = httpConn.getOutputStream();
*try* (*final* PrintWriter wr = *new* PrintWriter(
DefaultProperty./isEnableSocketTraceGW/ ? *new*
TracerOutputStream(os) : os )) {
*final* String text = action= + action + data= +
URLEncoder./encode/(data, DefaultProperty./httpEncoding/);
You should encode the action String, too.
wr.write(text); wr.flush();
*final* *int* respCode = httpConn.getResponseCode();
*if* (respCode != HttpURLConnection.*/HTTP_OK/*)
{
String info = Incorrect response from server, responseCode: +
respCode + , message: + httpConn.getResponseMessage();
*/log/*.error(info);
*throw* *new* SSYSException(SSYSCoreEx.*/ERR_UNKNOWN_ERROR/*,
info);
}
}
*if* (jSessionCookie == *null*)
{
jSessionCookie = getJSessionCookie(httpConn);
}
*final* InputStream inputStream = httpConn.getInputStream();
*try* (*final* BufferedReader reader = *new* BufferedReader(*new*
InputStreamReader(
(DefaultProperty./isEnableSocketTraceGW/ ?
*new* TracerInputStream(inputStream)
:
inputStream
)
, DefaultProperty./httpEncoding/)))
You probably want to use the *actual* encoding of the response.
{
*/log/*.trace(before readline(post));
String replyText = reader.readLine();
*/log/*.trace(after readline(post): [ + replyText + ]);
NReply nReply = PoolGson./fromJson/(replyText, NReply.*class*);
*if* (nReply == *null*) {
*final* String msg = corrupted reply, action: + action;
*/log/*.debug(msg);
*throw* *new* IOException(msg);
}
*return* *new* PostResponse(replyText, nReply, jSessionCookie,
nReply.id);
}
}
On the server side there is Tomcat 8.0.21 + APR connector.
Every time this heartbeat is sent I see in the Wireshark and
EtherDetect that new TCP connection is opened (SYN-SYNACK packets)
and after getting response from Tomcat connection is closed (FIN –
FINACK packets).
I was expecting that TCP connections will be reused but not closed.
Are you sending a Connection header to the server?
Is it problem in my client or it can be solved by Java and/or
Tocmat configuration?
That depends. IIRC, HttpURLConnection used to use KeepAlive *by
default* but that turned out to be a surprise to a lot of people and
caused resource issues. I'm not sure if Sun/Oracle changed their minds
about that and changed the default to be Connection: close.
I notice that you are *not* calling HttpURLConnection.disconnect(),
which is probably the correct decision given what you'd like to do.
I'd confirm that Connection: keep-alive is being used with your
connection, just in case.
- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVeO58AAoJEBzwKT+lPKRYWusP/0FnuVVOj8NCYvy84+ckpStZ
saV8srYNmlZiL9YLaMTEAEifPRndCFjWbBIjbAVAS2pFB25gxvkGl4WJTrz6KdkU
u89kVUtOjqwJ6aaNDuUmOuyv52wq5NyGWDcsmVX5WgaWCOxmRZK3TlVGWikjn0J+
W7Ta86nI3qtYeY9yq7S3BwR7wUmzHXDvWK9Z3eeh3v9W0PgmoUg8TMbBKH/3HhWs
GRBUYeotXjXpNqygaY0LOllTWSSQO/YLReStK4jcKzlOyGNoZrNpigbTJBberjg8
EltuquoyWlRRlL8BMglLVSfpX0NVJrToDEsDURiHQl614Fj7ZgBlmZgSVSQIdd50
vDdAZSFlzyAqnnYCa6f7vX2BMcV6nHRwoFsSWOz7oRy4ImkVttHoR84ZKzgylF5m
xmMKg8J/xcbBk+eZLOedYnOKElnIBtu66Lj8Rq+B1UT6T45pcN7ypbVYbzGTjWrM
Pq2+m9Jz5Ch/dsnjraW5ewbD3/N40LIBs8s8tUd4on2e2eK8OFuPGNbDm8gnd2hq
N0qOH33y+BjKt2XGneUesuB/0lrySBs6FcuBG+M5afyfkkgb+QV9UONRJwKSP0ad
jI4zJPQTkHjXefJjf5KvpPSAQJoPIzO6oCtExt9ijd/cE9uhLMGbmrHaswj8TcUM
NIxez4dHmc6cEgDIodAZ
=baJj
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
