Skip to content

ClassCastException when arangodb.acquireHostList=true #377

Closed
@wajda

Description

@wajda

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!

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions