Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Add self-diagnostics to PooledByteBufAllocator #1586

Open
trustin opened this Issue · 1 comment

3 participants

Trustin Lee David Oswell Scott Mitchell
Trustin Lee
Owner

Although it is not conclusive that PooledByteBufAllocator leaks, it will be very useful to have some information recorded and logged so that we can do some basic sanity checks, such as:

  • Check the amount of internal fragmentation
  • Validate and dump the internal data structure (and visualize?)
  • Dump the diagnostic information listed above on OOME automatically (or programmatically)
Trustin Lee trustin was assigned
David Oswell

I would add (if not covered under dump diag info) the ability to check number of outstanding references to ByteBuf returned from the pool. Or a PooledbyteBuf implementation that can be used in unit testing which does track the info. This can be useful for unit testing of handlers to ensure a handler doesn't do something silly like;
ByteBuf neverReleased = ctx.alloc().buffer();
or, in addition to above;
neverReleased.retain();
neverReleased.release(); //Still 1 reference after this.
and then exits the handler without releasing.

In unit testing the references could at least be checked to see if there are 1 or 0 outstanding ByteBuf references.

I often end up wrapping a ByteBuf with some other object to break out info, so ran into several scenarios of my own stupidity of not releasing things (Now I just implement ReferenceCounted for any object I wrap a bytebuf under to be safe). Also help find nuances such as a CompositeByteBuf doesn't call a retain on buffers added, but will call a release on each ByteBuf.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.