Gremlin Driver and frequently changing servers
In a containerised environment, hosts are frequently replaced and their IP address can change several times a day.
As far as I can tell, Gremlin Driver was designed for long-lived hosts given that:
(1) Contact Points are resolved on startup and a connection pool is assigned to them at that time - this makes varying contact points over time not possible I think?
(2) Unavailable hosts are retried but the list of hosts is not refreshed - wouldn't it make more sense to give up on hosts after a few retries and refresh the list of contact points?
I was wondering if the community had any guidance for containerised environments, if handling such cases within Gremlin Driver made sense, and if it'd be worth filing a JIRA ticket.
Thanks!
As far as I can tell, Gremlin Driver was designed for long-lived hosts given that:
(1) Contact Points are resolved on startup and a connection pool is assigned to them at that time - this makes varying contact points over time not possible I think?
(2) Unavailable hosts are retried but the list of hosts is not refreshed - wouldn't it make more sense to give up on hosts after a few retries and refresh the list of contact points?
I was wondering if the community had any guidance for containerised environments, if handling such cases within Gremlin Driver made sense, and if it'd be worth filing a JIRA ticket.
Thanks!
Solution
yes, this is a bit of an issue in some cases like the one you describe. a similar issue occurs for Neptune where it would be helpful if the drivers knew the cluster topology. you're basically left to periodically recreate the
ClusterAmazon Web Services
[Updated August 2021] The Gremlin Client for Amazon Neptune is now available from Maven Central. Some APIs have changed since this article was published. Please review the demo code in the GitHub repository for the latest examples of how to use the APIs. Amazon Neptune is a fast, reliable, fully managed graph database service that makes it easy ...
