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.

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

Fix OneTimeReadTimeoutHandler behavior #1235

Merged
merged 2 commits into from May 1, 2019

Conversation

dagnir
Copy link
Contributor

@dagnir dagnir commented May 1, 2019

Description

  • Extend ReadTimeoutHandler for timeout behavior
  • Remove self from pipeline once a message is read

Motivation and Context

Bug fix.

Testing

Screenshots (if appropriate)

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)

Checklist

  • I have read the CONTRIBUTING document
  • Local run of mvn install succeeds
  • My code follows the code style of this project
  • My change requires a change to the Javadoc documentation
  • I have updated the Javadoc documentation accordingly
  • I have read the README document
  • I have added tests to cover my changes
  • All new and existing tests passed
  • A short description of the change has been added to the CHANGELOG
  • My change is to implement 1.11 parity feature and I have updated LaunchChangelog

License

  • I confirm that this pull request can be released under the Apache 2 license

 - Extend ReadTimeoutHandler for timeout behavior
 - Remove self from pipeline once a message is read
ctx.pipeline().remove(this);
super.channelRead(ctx, msg);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't it be channelRead first and then remove?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so. If a downstream handler removes us first (for example if the channel is released and HandlerRemovingChannelPool removes it), then remove will fail; so we remove the read timeout handler first, then fire the read down the rest of the pipeline.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I see, yeah.

Is there any reason why super.channelRead is being used? Should we do ctx.fireChannelRead(msg) ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that would work, but technically this is just a specialized ReadTimeoutHandler so I think it makes more sense to just defer to it's channelRead impl.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at the source code of IdleStateHandler, there's some extra logic there. Probably doesn't matter for now, but I'd lean towards to using ctx.fireChannelRead directly just in case there's some broken change introduced in the future(somehow).

    @Override
    public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
        if (readerIdleTimeNanos > 0 || allIdleTimeNanos > 0) {
            reading = true;
            firstReaderIdleEvent = firstAllIdleEvent = true;
        }
        ctx.fireChannelRead(msg);
    }

Copy link
Contributor Author

@dagnir dagnir May 1, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's my point as well though. Not calling super.channelRead could also break behavior because extra logic there.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, yeah, I guess that makes sense.

@codecov-io
Copy link

codecov-io commented May 1, 2019

Codecov Report

Merging #1235 into master will decrease coverage by 0.06%.
The diff coverage is 50%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master    #1235      +/-   ##
============================================
- Coverage     59.27%   59.21%   -0.07%     
  Complexity     4661     4661              
============================================
  Files           750      750              
  Lines         23292    23288       -4     
  Branches       1744     1744              
============================================
- Hits          13806    13789      -17     
- Misses         8789     8804      +15     
+ Partials        697      695       -2
Impacted Files Coverage Δ Complexity Δ
.../http/nio/netty/internal/NettyRequestExecutor.java 61.62% <0%> (-0.34%) 29 <0> (ø)
.../nio/netty/internal/OneTimeReadTimeoutHandler.java 100% <100%> (ø) 2 <1> (ø) ⬇️
...o/netty/internal/utils/BetterFixedChannelPool.java 52.48% <0%> (-6.63%) 14% <0%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 691eca8...07d2b61. Read the comment docs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants