On Thu, Jan 9, 2025 at 3:17 PM Mark Thomas <ma...@apache.org> wrote: > > On 09/01/2025 14:01, ma...@apache.org wrote: > > This is an automated email from the ASF dual-hosted git repository. > > > > markt pushed a commit to branch main > > in repository https://gitbox.apache.org/repos/asf/tomcat.git > > > > > > The following commit(s) were added to refs/heads/main by this push: > > new 1f4175d65c Refactor so the buffered data is used directly rather > > than copied > > 1f4175d65c is described below > > > > commit 1f4175d65cd7bb44af7fa098e8160b084870865a > > Author: Mark Thomas <ma...@apache.org> > > AuthorDate: Thu Jan 9 14:01:18 2025 +0000 > > > > Refactor so the buffered data is used directly rather than copied > > > > This also aligns with other uses of o.a.catalina.connector.InputBuffer > > where a pre-populated buffer replaces InputBuffer#bb rather than the > > data being copied into the existing InputBuffer#bb > > This is in preparation for a fix for the high HTTP/2 memory usage > reported on the users list before the holidays. > > As far as I can tell, InputBuffer#bb - at least the 8kB buffer created > when the InputBuffer is created - is now never used. #setByteBuffer() is > always used to replace the existing buffer rather than copy data to the > existing buffer. > > Recycle could/should be setting InputBuffer#bb to null to avoid > retaining references to these (potentially large) buffers but that > creates issues as there are multiple code paths that access > InputBuffer#bb when it is expected to empty. If recycle sets it to null, > we get NPEs. > > My current plan is to create InputBuffer with bb set to a zero length > ByteBuffer and have recycle (re)set it to a zero length ByteBuffer. That > avoids the NPEs, avoids retaining references unnecessarily but (so far) > doesn't break anything. > > I have some more testing to do but hope to have something to commit by > the end of today.
That sounds like a good plan, hopefully with no hidden issues. Rémy > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org