You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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!
The text was updated successfully, but these errors were encountered:
* 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]>
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
andArangoDBAsync.Builder
, specifically in a way how the pools and connection factories are re-used for sync and async communications.As you can see both sync and async communication builders share the same
HostHandler
instance, and subsequently the sameHostResolver
that in turn points to aConnectionFactory
which has different implementations for sync and async variants. So according to the current architectureHostHandler
andHostResolver
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
andHostResolver
specifically for being used by theArangoExecutorSync
executor for theExtendedHostResolver
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!
The text was updated successfully, but these errors were encountered: