Let a managed server finish coming up before giving up on it - #121
Merged
Conversation
A run against a managed container failed twice over, and both failures reported the engine as broken when the harness was the one at fault. The readiness wait dials the port, and a server binds its port well before it speaks its own protocol on one. For Neo4j that gap is tens of seconds, so the first Ping got an EOF and the run ended saying the server was unreachable. A session against a server this run launched now retries for up to ninety seconds. A server the operator supplied still gets one attempt: that one is either up or not. Past that, the load picked an import directory by looking for a local install, found this machine's homebrew one, wrote a CSV into it and asked a server in a container to read it. The directory is now proved instead of assumed, by writing one row and reading it back through the server, and a directory the server cannot see falls back to UNWIND batching. linkbench smoke now runs end to end against a managed neo4j container, all ten queries, and with the sampler it is the first run to report what that server costs: 1.3 GiB held and 516 MiB on disk for a 553 KiB dataset.
12 tasks
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
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.
Part of #56. The managed container path was broken in two places and neither failure was the engine's.
First, the readiness wait dials the port, and a server binds its port well before it speaks its own protocol on one. For neo4j that gap is tens of seconds, so the first Ping got an EOF and the run ended with "neo4j: unreachable at bolt://127.0.0.1:32769 (is the server up?)" against a server that was up and starting. A session against a server this run launched now retries for up to ninety seconds. A server the operator supplied still gets one attempt, since that one is either up or not and waiting a minute and a half to say so helps nobody.
Second, the load resolves an import directory by asking the server and then falling back to local-install heuristics. On this machine the fallback found homebrew's import directory, wrote the CSV there, and asked a server inside a container to read it, which ended the load with
Couldn't load the external resource at: file:///gb-3991357500.csv. The directory is now proved rather than assumed: one row is written carrying the file's own name and read back through the server, and a directory the server cannot see leaves importDir empty so the load falls back to UNWIND batching. That also covers the case nobody had hit yet, a local install that is not the server on the other end of the connection.linkbench smoke now runs end to end against a managed neo4j container, all ten queries, and it is the first run to report what that server costs:
The peak rss row for that same run reads 22.2 MiB, which is the Bolt driver in this process. That is the number the sampled rows replace.
go test ./... green, and the retry has unit tests over a stub engine so it does not need a container to be checked.