-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix the read timeout implementation in NettyStream (#636)
Both the new approach and the original one achieve the guarantee that there are no concurrent read timeouts scheduled for a channel. This is an essential property needed for a timeout implementation, let us call it "at-most-one". The original approach of achieving the at-most-one property: - Schedule timeouts only by an event loop thread. - If another thread needs to schedule a timeout, it submits a new scheduleTimeout task to the channel's event loop (asynchronous timeout scheduling). - The scheduleTimeout task schedules a new timeout if none is scheduled. The original approach allowed executions in which a scheduleTimeout task runs after completion of the read operation that submitted the task, which resulted in unexpected timeout exceptions. The new approach achieves the at-most-one property by using a lock. As a result, timeouts can be scheduled by any thread and there is no asynchronous timeout scheduling. This means we cannot miss removing a timeout because it was submitted for scheduling, but has not been scheduled yet. Other notable changes: - [related bug fix] NettyStream now must always respect the requested additional timeout. The original implementation had a chance to ignore the requested additional timeout and schedule a timeout with the default delay. This is again due to the asynchronous timeout scheduling in the original approach. - [performance optimization] Public read methods do not schedule timeouts anymore if the requested number of bytes is available right away. - [performance optimization] Netty channel handlers do not try to schedule timeouts anymore, timeouts may be scheduled only by the public read methods. Trying to schedule timeouts from the method handleReadResponse was unnecessary even in the original approach. - [performance optimization] NettyStream does not produce excessive garbage by re-creating PendingReader objects each time a new piece of data arrives for a pending reader. - [code improvement] The fields NettyStream.pendingReader, pendingException are always written/read inside synchronized blocks that use the same NettyStream object, so they can be plain. Marking them volatile is unnecessary and potentially misleading. - [code improvement] ReadTimeoutHandler was removed because it wasn't acting as a handler and was not needed. JAVA-3920
- Loading branch information
Showing
2 changed files
with
134 additions
and
138 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.