Skip to content

ClassCastException when arangodb.acquireHostList=true #377

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

Closed
wajda opened this issue Mar 22, 2021 · 0 comments · Fixed by #378
Closed

ClassCastException when arangodb.acquireHostList=true #377

wajda opened this issue Mar 22, 2021 · 0 comments · Fixed by #378
Assignees

Comments

@wajda
Copy link
Contributor

wajda commented Mar 22, 2021

This is the same issue that was originally found in the arangodb-java-driver-async module. See: arangodb/arangodb-java-driver-async#21

After taking a closer look it occurred to me that the main problem is localized between ExtendedHostResolver and ArangoDBAsync.Builder, specifically in a way how the pools and connection factories are re-used for sync and async communications.

final HostResolver hostResolver = createHostResolver(createHostList(max, connectionFactory), max, connectionFactory);
final HostHandler hostHandler = createHostHandler(hostResolver);
return new ArangoDBAsyncImpl(asyncBuilder(hostHandler), util, syncBuilder(hostHandler), hostResolver, new ArangoContext());

As you can see both sync and async communication builders share the same HostHandler instance, and subsequently the same HostResolver that in turn points to a ConnectionFactory which has different implementations for sync and async variants. So according to the current architecture HostHandler and HostResolver classes even though don't directly depend on but de facto imply a concrete communication type (sync or async), and hence cannot be reused between them.

I'm not sure if I comprehend all the details and reasoning behind the current connection model and responsibility splitting between abstractions, but I have a feeling that some dependencies aren't justified, and that the issue could be fixed by applying some refactoring and rewire the classes a little bit.

Nevertheless I have prepared a quick and dirty fix that avoids refactoring and seemingly works (according to my tests and my understanding of how the things are organized in the driver). The way I approached it was creating an additional pair of HostHandler and HostResolver specifically for being used by the ArangoExecutorSync executor for the ExtendedHostResolver to connect to /_api/cluster/endpoints. This separates the sync executor used internally by the host resolver from the primary communication chain used to execute the client application requests.

@rashtao
I'll create a PR shortly. Could you please take a look at it, if it's something that makes sense?
Thank you!

wajda added a commit to wajda/arangodb-java-driver that referenced this issue Mar 22, 2021
…er for the Execution used to call `/_api/cluster/endpoints`
@rashtao rashtao self-assigned this Mar 23, 2021
rashtao added a commit that referenced this issue Mar 23, 2021
* isuse #377 - use a separate (sync) HostHandler and HostResolver for the Execution used to call `/_api/cluster/endpoints`

* re-enabled acquireHostList in async tests

Co-authored-by: Michele Rastelli <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants