-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark,
On 1/11/19 13:50, Mark Thomas wrote: > On 11/01/2019 17:31, Christopher Schultz wrote: >> Mark, >> >> On 1/11/19 12:23, Mark Thomas wrote: >>> On 10/01/2019 19:55, Mark Thomas wrote: >> >>> <snip/> >> >>>> I've just tracked down one leak although it is a relatively >>>> small one. Next steps are to fix that leak and then find the >>>> next one. And then repeat. >> >>> Found it. >> >>> The leak impacted NIO and NIO2 when used with OpenSSL. >> >>> The bug is in Tomcat Native. I have a fix that I am currently >>> testing. That fix should be in the next Tomcat Native release. >> >>> For those interested in the technical details, Tomcat Native >>> allocates some Native memory to track various attributes of >>> each connection. >> >>> In APR/Native this memory is allocated from a new APR memory >>> pool that is associated with the connection. When the >>> connection closes, the pool is destroyed and the memory freed. >>> All is good. >> >>> In NIO[2]+OpenSSL the per connection memory was allocated from >>> the APR memory pool associated with the Connector so the memory >>> was not released until the Connector was stopped. The fix is to >>> create a pool per connection and use that for the per >>> connection allocations. With a fix to do that in place, memory >>> use is now broadly static under extended TLS load. >> >> Nice work. >> >> I think you can file this under "stuff we knew might be a >> problem" and was the reason we were considering >> reference-counting, etc. to make sure we didn't leak >> *connections*. Here, the connection was cleaned-up, but some of >> the associated data wasn't being cleaned from a shared cache. Do >> I have that right? > > Yes. The cache in this case was a memory pool. Think of it as > managed malloc. You can destroy pool and clean up all the memory > allocated through it without having to call free on each of the > individual allocations. It was a tcn_ssl_ctxt_t structure that > wasn't being released. It is a collection of 4 pointers so it > wasn't too big but one for every connection mounts up over time. Does this affect all versions of Tomcat where JSSE+OpenSSL are in use? Sounds like it would. >> Is there a way, short of bouncing Tomcat, to flush that cache? >> For example, bouncing or otherwise re-initializing the connector >> or something like that? > > Yes, but I'm not sure how much practical use it is. You need to > unbind the server socket - the necessary clean-up happens > AbstractEnpoint.unbind(). That will happen on Connector.stop() or > Connector.destroy() depending on bindOnInit. The issue is that > unbinding the socket is going to cause connections to be dropped. > The end result will be similar to bouncing Tomcat although it > should be quicker (no need to reload webapps). I was mostly asking on behalf of others. Some people may find it easier to bounce their connectors periodically rather than upgrade right away. - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlw5BYAACgkQHPApP6U8 pFhXCxAArAW1vaWcaMsT84rmfBMFGEWhDetSG7Eb51h631yicFnU/XkJD6pYa1JY xq1LKPbA/MDlTM0saxgmd1u2Os5YoHg5Gk4jHgfFdAiUoZDdEPMheXcvNauZQgmq +jg13Zh9aNotsIPTtBySlwKlkfJ04i8K80iTZ/HVnMVpWDczpqA9g0DEHkvpMbj6 85lZM4fMExLUswSCPJzliqCeyt7KJr0awlAqL7KUo6ZoGJR5CSCQOaRbZUhNx9w3 wrothMP6J2WHu1cUN+gsMze9dYeicKPoR1aCWrUk6w4PsoelVrS+UfPQEULdTZLi 3V3Ezxdvbv6tnrPNHxuQf/FrpSqU0+T1SocsnnNAT7/f/451Gd9fcNF/R9uyVjBE Uy4W3gumpnZtC4g6XBmNw5zOF2ltei/2iJjO7WGHOdW87iOfkOoszdj9smMX/MOP dMlNBejckOfOgJsfT6DZ3ZbvzAbO3WpK2W8AMsGTXhEDkuHsrswzx1/f7jzOFDsz ZNPpm8q/wLzuBSRDkc9r0hMivJPdWuUWoUkn2GTbB1DnuH7jLbr09Hk1YMU+zsvF jNEgpI5ZmNDjuP3UHkupNzotlMNh20stvmSXFKqjXHL4RHCtg9XkNixW11Z9roWT VSHj+Sd28AnxccI9GpT0EmH25cyAct26e75yJonw92PTyfrPLcc= =MkQ/ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
