Ensure a single handler manages channel's auto-read #528
Conversation
This file contains hidden or 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
`PullAllResponseHandler` is responsible for receiving a stream of records. Stream might be very large and handler tries to not fetch if fully into memory. It applies a network-level backpressure by disabling/enabling auto-read property of the underlying Netty channel. This property tells channel to not read from the network. Auto-read is disabled when number of queued records goes beyond the threshold. Management of auto-read turned out to be problematic for nested queries within a single transaction. Nested queries result in multiple `PullAllResponseHandler`s being added to the queue of handlers. They will try to manage auto-read concurrently and can sometimes disable it completely. Callers would then be blocked and unable to proceed. This is not a problem for `Session#run()` because every such call ensures there was a logical SYNC and the previous query has completed and its result is buffered. This commit fixes a problem by making only a single installed handler manage the channel's auto-read property. Making sure there only exists a single such handler is the responsibility of `InboundMessageDispatcher`. Auto-read is enabled when new auto-read managing handler is installed. Previous such handler is disabled.
lutovich
force-pushed
the
1.6-tx-with-nested-queries
branch
from
a1504c1 to
5c968ca
Compare
ali-ince
reviewed
Sep 11, 2018
driver/src/main/java/org/neo4j/driver/internal/async/inbound/InboundMessageDispatcher.java
Show resolved
Hide resolved
Make sure `InboundMessageDispatcher` does not hold on to the last auto-read management handler after it is removed from the queue of all handlers.
ali-ince
approved these changes
Sep 11, 2018
To make sure it does not influence the auto-read status of the channel. Also restore default value of auto-read for channel when such handler is removed. This change is needed to avoid removing a handler that has just disabled auto-read. This is possible when handler receives a RECORD that causes it to disable auto-read and then receives a SUCCESS message, which causes it to be dequeued with auto-read being disabled.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PullAllResponseHandleris responsible for receiving a stream of records. Stream might be very large and handler tries to not fetch if fully into memory. It applies a network-level backpressure by disabling/enabling auto-read property of the underlying Netty channel. This property tells channel to not read from the network. Auto-read is disabled when number of queued records goes beyond the threshold.Management of auto-read turned out to be problematic for nested queries within a single transaction. Nested queries result in multiple
PullAllResponseHandlers being added to the queue of handlers. They will try to manage auto-read concurrently and can sometimes disable it completely. Callers would then be blocked and unable to proceed. This is not a problem forSession#run()because every such call ensures there was a logical SYNC and the previous query has completed and its result is buffered.This PR fixes a problem by making only a single installed handler manage the channel's auto-read property. Making sure there only exists a single such handler is the responsibility of
InboundMessageDispatcher. Auto-read is enabled when new auto-read managing handler is installed. Previous such handler is disabled.Also renamed
InboundMessageDispatcher#queue()toInboundMessageDispatcher#enqueue().Fixes neo4j/neo4j#12033