Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

AbstractNioMessageChannel may keep reading but never call fireInboundBufferUpdated() and so trigger an OOM #1388

Closed
normanmaurer opened this issue May 23, 2013 · 0 comments
Closed

AbstractNioMessageChannel may keep reading but never call fireInboundBufferUpdated() and so trigger an OOM #1388

normanmaurer opened this issue May 23, 2013 · 0 comments
Assignees
@normanmaurer
Labels
defect
Milestone
4.0.0.Final

Comments

@normanmaurer
Copy link
Member

All messages based channels that extend AbstractNioMessageChannel may keep reading messages in the MessageBuf but fail to call fireInboundBufferUpdated() until there is nothing left to read. This may cause problems as allocated ByteBuf for example when used in DatagramPacket will not get released at all in this time. This can lead to an OOM really quickly.

See also:
http://stackoverflow.com/questions/16687425/the-udp-server-throws-oom-exception-when-feed-data-in-a-high-rate
@ghost ghost assigned normanmaurer May 23, 2013
normanmaurer pushed a commit that referenced this issue May 23, 2013
[#1388] Ensure AbstractNioMessageChannel based Channels will call fir…
50ac0cd 
…eInboundBufferUpdated() soon enough to release resources
normanmaurer pushed a commit that referenced this issue May 23, 2013
[#1388] Correctly break the loop on exceptions
5398792
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@normanmaurer normanmaurer

Labels
defect
Projects
None yet
Milestone
4.0.0.Final
Development

No branches or pull requests
1 participant
@normanmaurer