https://bz.apache.org/bugzilla/show_bug.cgi?id=59904
--- Comment #2 from Huxing Zhang <huxing.zh...@gmail.com> --- We saw two issues in this case: 1) the size of org.apache.tomcat.util.http.Cookies#scookies array never gets shrunk after recycle, once it is dynamically resized. 2) the number of org.apache.tomcat.util.http.ServerCookie object can be dramatically large, which might lead to memory leak. A maxHeaderSize of 8k has limit the number of ServerCookie object to no more than 2k, assuming each cookie is 4 bytes (e.g. 'a=b;'). This may have limited impact for a web application with low concurrency. However, for a heavily concurrent, NIO-based connector, this may have a huge impact. Suppose a malicious client is sending 2k concurrent request, each sending 2k cookies, at tomcat side there will be 2k * 2k = 4m ServerCookie objects. Since the default maxConnection value is 10k for NIO, there can be at most 20m Server Cookies objects, and cannot be recycled because of 1). Proposal: 1) We propose to shrink the org.apache.tomcat.util.http.ServerCookie object array back to its initial size after recycling org.apache.tomcat.util.http.Cookies object. 2) We propose to add a maxCookieCount configuration to limit the number of cookie to process. When exceeding the limit, extra data are ignored and a warning message is logged. The default value of maxCookieCount shall be unlimited to be compatible with current behavior, and configurable via server.xml. We are currently working on a patch of 1） and 2). -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
