Closed ekampp closed 3 years ago
Hi @ekampp,
Thank you for reporting this issue. It has actually been discovered internally too and we are going to fix it. An update will be posted here later on.
For the time being you might want to try the latest 4.2.1 version, which fixed another issue, but may result in a more reliable behaviour (especially in combination with the retry mechanism in the tx functions).
@injectives, thank you for the quick and positive feedback.
To be crystal clear, when you said "For the time being, you might want to try the latest 4.2.1 version," did you mean java driver or neo4j version?
I meant the Java Driver :)
@ekampp, we have just released a new Neo4j Java Driver version 4.2.4 that fixes this issue.
Please let us know if you experience this problem again with the new version.
@injectives, I will let you know if anything pops up again. Thanks for your help!
Hi team.
First off, thanks for a super nice tool, and sorry if we're just not understanding it correctly. We have recently migrated to JRuby to leverage the java driver for a variety of reasons.
We realized that neo4j-java-driver is incorrectly operating with DNS resolution mode.
Steps to reproduce
The following connection URI was used:
The DNS query for neo4j.infra.prod.internal returns 3 addresses:
When all aforementioned members are available, everything is fine. The driver connects to one of them successfully and gets the neo4j routing table:
However, if one of those members is down and the
gethostbyname()
library call returns its address at the top of the resulting list, then the neo4j-java-driver will fail to bootstrap:Expected behavior
When a node member goes away, the connection should roll over to the next online member.
Actual behavior
The driver is not trying to connect to other hosts returned in the list.
Logs
logs.txt