Skip to content

netty: Fix receipt of ClosedChannelException instead of actual error.… - #2255

Merged
buchgr merged 2 commits into
grpc:masterfrom
buchgr:closedchannel
Sep 12, 2016
Merged

netty: Fix receipt of ClosedChannelException instead of actual error.…#2255
buchgr merged 2 commits into
grpc:masterfrom
buchgr:closedchannel

Conversation

@buchgr

@buchgr buchgr commented Sep 12, 2016

Copy link
Copy Markdown
Contributor

Fixes #1330.

Our API allows pings to be send even after the transport has been shutdown. We currently
don't handle the case, where the Netty channel has been closed but the NettyClientHandler
has not yet been removed from the pipeline, correctly. That is, we need to query the shutdown
status whenever we receive a ClosedChannelException.

Also, some cleanup.

…ixes grpc#1330.

Our API allows pings to be send even after the transport has been shutdown. We currently
don't handle the case, where the Netty channel has been closed but the NettyClientHandler
has not yet been removed from the pipeline, correctly. That is, we need to query the shutdown
status whenever we receive a ClosedChannelException.

Also, some cleanup.
finalPing.failed(future.cause());
Throwable cause = future.cause();
if (cause instanceof ClosedChannelException) {
cause = lifecycleManager.getShutdownThrowable();

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

What if getShutdownThrowable() is null?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Then null is propagated to the PingCallback. The API spec seems to allow it. If our code works correctly, we should never get a ClosedChannelException without the ClientTransportLifeCycleManager knowing about it, no?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I don't believe PingCallback was intended to allow a null cause. And such a null cause is very difficult to debug.

We should just create a status in that case, like done elsewhere, maybe with the message "Ping failed but for unknown reason".

@ejona86

ejona86 commented Sep 12, 2016

Copy link
Copy Markdown
Member

LGTM

@buchgr

buchgr commented Sep 12, 2016

Copy link
Copy Markdown
Contributor Author

@ejona86 PTAL

@ejona86

ejona86 commented Sep 12, 2016

Copy link
Copy Markdown
Member

LGTM

@buchgr
buchgr merged commit 4aadf55 into grpc:master Sep 12, 2016
@lock lock Bot locked as resolved and limited conversation to collaborators Jan 21, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Receiving ClosedChannelException instead of actual error

2 participants