https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
--- Comment #16 from qixiaobo...@gmail.com --- (In reply to Ty from comment #14) > > OOMEs can happen for a number of reasons -- not always complete > > heap-exhaustion. > > Very true, I forgot about the "initialize an object array of > size=Integer.MAX_VALUE" operations that OOME before they even begin. > > > I'd be interested to see if JMX reports an increase in the OOME count when > > these > > zero-length chunks are dropped from the responses. > > Once the heap size was increased, I see a very sharp and short-lived (i.e. > garbage-collectable) increase in OldGen utilization. From memory, a spike > of about 850MB. I think that's what you're asking about. > > Besides the probably-swallowed OOME, that just leaves the mystery of a > response that (when under memory constraints) is missing the last chunk but > otherwise is complete. I'd wager a third-party library is to blame -- in > our case and in OP's case, there is a JSON library in the mix-- but what is > strange to me is the response isn't compliant with the RFC spec for > Transfer-Encoding: chunked, at least according to my reading of it: a > response can't be considered complete without the zero byte chunk, but the > server seems to think it is. No oom -- 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
