@@ -362,49 +362,6 @@ public ByteBufAllocator getDelegate() {
362
362
}
363
363
}
364
364
365
- static class TrashingByteBuf extends WrappedByteBuf {
366
-
367
- private boolean trashed = false ;
368
-
369
- protected TrashingByteBuf (ByteBuf buf ) {
370
- super (buf );
371
- }
372
-
373
- @ Override
374
- public boolean release () {
375
- if (refCnt () == 1 ) {
376
- // see [NOTE on racy trashContent() calls]
377
- trashContent ();
378
- }
379
- return super .release ();
380
- }
381
-
382
- @ Override
383
- public boolean release (int decrement ) {
384
- if (refCnt () == decrement && refCnt () > 0 ) {
385
- // see [NOTE on racy trashContent() calls]
386
- trashContent ();
387
- }
388
- return super .release (decrement );
389
- }
390
-
391
- // [NOTE on racy trashContent() calls]: We trash the buffer content _before_ reducing the ref
392
- // count to zero, which looks racy because in principle a concurrent caller could come along
393
- // and successfully retain() this buffer to keep it alive after it's been trashed. Such a
394
- // caller would sometimes get an IllegalReferenceCountException ofc but that's something it
395
- // could handle - see for instance org.elasticsearch.transport.netty4.Netty4Utils.ByteBufRefCounted.tryIncRef.
396
- // Yet in practice this should never happen, we only ever retain() these buffers while we
397
- // know them to be alive (i.e. via RefCounted#mustIncRef or its moral equivalents) so it'd
398
- // be a bug for a caller to retain() a buffer whose ref count is heading to zero and whose
399
- // contents we've already decided to trash.
400
- private void trashContent () {
401
- if (trashed == false ) {
402
- trashed = true ;
403
- TrashingByteBufAllocator .trashBuffer (buf );
404
- }
405
- }
406
- }
407
-
408
365
static class TrashingCompositeByteBuf extends CompositeByteBuf {
409
366
410
367
TrashingCompositeByteBuf (ByteBufAllocator alloc , boolean direct , int maxNumComponents ) {
0 commit comments