Comments on: How to Read HttpClient Logging and Prevent Connection Leaks2022-05-07T02:07:40.833Zhttps://michaelscepaniak.com/2010s/how-to-read-httpclient-logging-and-prevent-connection-leaks/https://michaelscepaniak.com/favicon.icoBy: Michael Scepaniak2022-05-07T02:07:40.833Z2022-05-07T02:07:40.833Zhttps://michaelscepaniak.com/2010s/how-to-read-httpclient-logging-and-prevent-connection-leaks/#comment-k2324zhhMichael Scepaniak
<p>Fernando,</p>
<p>While reading my response, please keep in mind that I wrote this article more than 6 years ago and haven't done any Java development for many years.</p>
<p>My take is that the connection pool will help to reduce the overhead of tearing down and re-establishing connections to an endpoint that is accessed repeatedly. Those connections are not going to start being made (and kept alive) until client code requests them. As demand warrants, those connections will be kept alive for a period of time, with the hope/assumption being that more requests will be initiated to make use of those ready and waiting connections. If those subsequent requests never come, those connections that were being kept alive will eventually be closed. Given that behavior, I characterize terms such as "all the time", "permanently", and "force to reopen" as a bit extreme.</p>
<p>I was never completely clear as to what exactly "route allocated" and "kept alive" meant, and how those counts interrelated to each other. My general interpretation was that "kept alive" referred to connections that had been used in the past, were not currently in-use, and were ready to be used for new requests. But, this also seemed to apply to connections with pending responses. My observations (captured in my article) of pool activities and the impacts of those activities on the counts were not 100% predictable. It's possible that this was due to weaknesses in the pool's logging implementation.</p>
<blockquote>
<p>Where do I see the initial connections configured from the pool?</p>
</blockquote>
<p>There are no initial connections. From what I remember, connections are not "pre-created".</p>
<p>I hope this helps.</p>
<p>Mike....</p>
<img src="https://michaelscepaniak.com/cdn/log-blog.png?u=%2F2010s%2Fhow-to-read-httpclient-logging-and-prevent-connection-leaks%2Ffeed%2F&s=200">By: Fernando2022-05-06T10:33:20.910Z2022-05-06T10:33:20.910Zhttps://michaelscepaniak.com/2010s/how-to-read-httpclient-logging-and-prevent-connection-leaks/#comment-7cmngqjmFernando
<p>Hi, great post and analysis!. But I still dont get the next points:</p>
<ul>
<li>When you say "A connection to myhost has been leased (from the connection pool) and given a unique ID, but not opened". You mean there is Java connection object created but not opened to the target? But is not main purpose of the pool to have opened connections all the time and not just have the connections objects created? I thought the pool would be permanently checking its http connections from the pool and if they are not opened, force to reopen them in order when somebody wants to use them, has a http opened connection.</li>
</ul>
<p>-route allocated: 4=> means that there are 4 http connections now in use?. If this is like this, "total kept alive" should be the same, right?</p>
<p>-total kept alive:3 => means that there are 3 http connections live, right? But these connections can be in the pool waiting for somebody to use them or leased from the pool, right?</p>
<ul>
<li>Where do I see the initial connections configured from the pool? From the beginning logs I get the next. I see all are 0<br>
2022-05-06 10:24:41.301 DEBUG [conac-springboot-microlito,13c72be0abe1834b,d48772ce6e98624f,true] 1 --- [io-8080-exec-39] h.i.c.PoolingHttpClientConnectionManager : Connection request: [route: {}-><a href="http://acelera-springboot-conector-fix-service:8080" rel="nofollow">http://acelera-springboot-conector-fix-service:8080</a>][total kept alive: 0; route allocated: 0 of 5; total allocated: 0 of 10]</li>
</ul>
<p>Thanks</p>
By: Michael Scepaniak2020-02-06T15:20:08Z2020-02-06T15:20:08Zhttps://michaelscepaniak.com/2010s/how-to-read-httpclient-logging-and-prevent-connection-leaks/#comment-847692Michael Scepaniak
<p>You're welcome! Thank you for the appreciative comment.</p>
By: Pankaj2020-02-06T05:14:17Z2020-02-06T05:14:17Zhttps://michaelscepaniak.com/2010s/how-to-read-httpclient-logging-and-prevent-connection-leaks/#comment-847600Pankaj
<p>Thank you this post! It helped me understand the apache http log messages better. I have a related problem of connection leak. I was not closing the connection. It is sorted now.</p>
By: Michael Scepaniak2018-09-24T20:26:07Z2018-09-24T20:26:07Zhttps://michaelscepaniak.com/2010s/how-to-read-httpclient-logging-and-prevent-connection-leaks/#comment-809147Michael Scepaniak
<p>Thank you for the comment and the note of appreciation. It makes my day. Good luck!</p>
<p>Mike...</p>
By: Arjon2018-09-07T19:46:59Z2018-09-07T19:46:59Zhttps://michaelscepaniak.com/2010s/how-to-read-httpclient-logging-and-prevent-connection-leaks/#comment-808849Arjon
<p>Thank you this post! It helped me understand the apache http log messages better. I have a related problem, though different from a connection leak, namely that somehow the requests on my connections are timing out the same millisecond they are set up, logging "http-outgoing-104 << "[read] I/O error: Read timed out" right away.</p>
<p>I was thinking of a previous connection not being shut down properly while still being in the pool, so added a "Connection: close" header that the server responds with... So I think I've shut that possibility out now.</p>
<p>Still a mystery why I'm seeing the close, so I posted it on SO: <a href="https://stackoverflow.com/questions/52227231/read-i-o-error-read-timed-out-immediately-upon-sending-headers" rel="nofollow">https://stackoverflow.com/questions/52227231/read-i-o-error-read-timed-out-immediately-upon-sending-headers</a>. But your post helped me on the way to understanding the logging entries, thank you.</p>
By: Michael Scepaniak2017-03-18T15:09:39Z2017-03-18T15:09:39Zhttps://michaelscepaniak.com/2010s/how-to-read-httpclient-logging-and-prevent-connection-leaks/#comment-800148Michael Scepaniak
<p>That's great, Ferez. Nice job. 😃</p>
By: Ferez2017-03-18T14:01:14Z2017-03-18T14:01:14Zhttps://michaelscepaniak.com/2010s/how-to-read-httpclient-logging-and-prevent-connection-leaks/#comment-800147Ferez
<p>I appreciate your concern Mike. I finally found the answer, you could check the thread again.</p>
<p>Ferez</p>
By: Michael Scepaniak2017-02-28T10:52:04Z2017-02-28T10:52:04Zhttps://michaelscepaniak.com/2010s/how-to-read-httpclient-logging-and-prevent-connection-leaks/#comment-799786Michael Scepaniak
<p>Thanks, Ferez. While I got close enough to this to be able to understand what the HttpClient library is doing, I didn't get to the point where I understood why - at least not in depth. So, unfortunately, I'm not able to shed any light on your SO question. Good luck.</p>
<p>Mike....</p>
By: Ferez2017-02-28T06:47:27Z2017-02-28T06:47:27Zhttps://michaelscepaniak.com/2010s/how-to-read-httpclient-logging-and-prevent-connection-leaks/#comment-799784Ferez
<p>Greate post, thank you very much.</p>
<p>I have a problem with the HttpClient log and need help. Would you please take a look at my problem posted in Stack Overflow?</p>
<p><a href="http://stackoverflow.com/questions/42469280/unexpected-connection-close-in-httpclient" rel="nofollow">http://stackoverflow.com/questions/42469280/unexpected-connection-close-in-httpclient</a></p>
<p>Regards,</p>
<p>Ferez</p>