Add self-diagnostics to PooledByteBufAllocator #1586

Open
trustin opened this Issue Jul 16, 2013 · 1 comment

3 participants

@trustin
The Netty Project member

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 trustin was assigned Jul 16, 2013
@doswell

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.

@trustin trustin modified the milestone: 5.0.0.Alpha3 Mar 7, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment