-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
inprocess: Fix listener race if transport is shutdown while starting #11214
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everywhere already handles a null being returned from start, so LGTM.
Some of the tests are checking for transportReady not being called anywhere rather than just not after shutdown. |
I think after this change it will always be null. But it'll be invasive to make the return value
That's only in the case that the transport is expected to not connect. In this case, in-process is probably the only transport that would connect so quickly, so the test will probably not catch anything in other transports. But there's also no reason to make it specific to in-process. (AbstractTransportTest actually was created as tests for in-process transport. And then we saw "we should run these tests against all transports" with only a few outliers.) |
I was referring to:
There were more of these against all versions for your initial commit |
Returning the runnable did nothing, as both the start method and the runnable are run within the synchronization context. I believe the Runnable used to be required in the previous implementation of ManagedChannelImpl (the lock-based implementation before we created SynchronizationContext). This fixes a NPE seen in ServerImpl because the server expects proper ordering of transport lifecycle events. ``` Uncaught exception in the SynchronizationContext. Panic! java.lang.NullPointerException: Cannot invoke "java.util.concurrent.Future.cancel(boolean)" because "this.handshakeTimeoutFuture" is null at io.grpc.internal.ServerImpl$ServerTransportListenerImpl.transportReady(ServerImpl.java:440) at io.grpc.inprocess.InProcessTransport$4.run(InProcessTransport.java:215) at io.grpc.SynchronizationContext.drain(SynchronizationContext.java:94) ``` b/338445186
3aa0a0b
to
eaef45f
Compare
Returning the runnable did nothing, as both the start method and the runnable are run within the synchronization context. I believe the Runnable used to be required in the previous implementation of ManagedChannelImpl (the lock-based implementation before we created SynchronizationContext).
This fixes a NPE seen in ServerImpl because the server expects proper ordering of transport lifecycle events.
b/338445186