Description
Rossen Stoyanchev opened SPR-17025 and commented
This came up from a discussion about having a client filter to enforce a limit on the content length of the response. Possibly buffering the content received before the limit and having an exception with the buffered content. DataBufferUtils#join could be very useful, if inserted after the limit enforcement.
Even beyond such a filter, the join method is used in a lot of decoders, and can leak pooled buffers in case of errors while reading. This could be considered an improvement but I've marked it as a bug only because I don't see any options to work around the issue.
This issue should also look at all the places (like codecs) where we are queuing buffer in queues and clean them accordingly in case of errors.
Affects: 5.0.7
Issue Links:
- Add ExchangeFilterFunction that enforces limit on the response size [SPR-16989] #21527 Add ExchangeFilterFunction that enforces limit on the response size
- ClientResponse's body ignored on UnsupportedMediaTypeException [SPR-17054] #21592 ClientResponse's body ignored on UnsupportedMediaTypeException
- Proper way to dispose of Response [SPR-17268] #21801 Proper way to dispose of Response
- Review DataBuffer handling code for proper release in case of error or cancellation [SPR-17408] #21941 Review DataBuffer handling code for proper release in case of error or cancellation
- DataBufferUtils does not release DataBuffer on error cases [SPR-16782] #21322 DataBufferUtils does not release DataBuffer on error cases
- DataBufferUtils#takeUntilByteCount checks one extra buffer but does not release it [SPR-17118] #21655 DataBufferUtils#takeUntilByteCount checks one extra buffer but does not release it
- Use doOnDiscard to free internally queued data buffers [SPR-17246] #21779 Use doOnDiscard to free internally queued data buffers