You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
Referenced from: commits 259b2ca, a006073, 196c0ad
The text was updated successfully, but these errors were encountered: