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

Reply via email to