[
https://issues.apache.org/jira/browse/ATLAS-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hemanth Yamijala updated ATLAS-571:
-----------------------------------
Attachment: ATLAS-571.patch
Attaching a patch that should be applied on top of ATLAS-511 and ATLAS-513.
The changes in the patch are as follows:
* Moved some classes around into common so that the dependencies on AtlasClient
remain unchanged even with HA.
* Provided the ability to create an AtlasClient object without giving a base
URL. If HA mode is enabled, this causes an automatic detection of the active
instance. If not, it just picks up the atlas.rest.address property from config.
* Specific failures in API calls from the client that indicate a loss of
connectivity with the service (specifically a Jersey ClientHandlerException)
cause a reset of the current Jersey client and re-initialization with the new
active instance.
* After the re-initialization, the API call is repeated to the new active
instance. In order to make these changes a little intelligently, (i.e. not need
to put the re-initialization and retry logic everywhere) I did the following
** Introduced a wrapper API that wraps around all calls to Atlas server.
** For this API to repeat a call, a closure kind of interface is defined and
used by the existing APIs of AtlasClient. This closure defines what resource
should be created and how so that the retry can happen.
* The checks for active atlas server happen with a configurable number of
retries and sleep interval.
* New unit tests added to test the selection of active server address and the
retry logic.
As can be seen, this became fairly more involved than what I thought it would
be. That is primarily because I wanted to make the AtlasClient do the right
thing automatically without any change to users of this class in the failover
scenarios.
I tested QuickStart with this change and in HA mode causing failovers. (Note
that I did not change QuickStart itself). I saw that except in one instance the
failover happened transparently and QuickStart finished successfully.
The one case where it failed was a slightly more tricky one, where an entity
got created in the Service before the failover, but the response did not reach
the client. Hence when the AtlasClient retried the operation, the service
reported back that the data is already created. However, this is not the
response QuickStart expects and hence it failed. Will fix this in a later JIRA.
> Modify Atlas client for necessary changes in context of HA
> ----------------------------------------------------------
>
> Key: ATLAS-571
> URL: https://issues.apache.org/jira/browse/ATLAS-571
> Project: Atlas
> Issue Type: Sub-task
> Reporter: Hemanth Yamijala
> Assignee: Hemanth Yamijala
> Attachments: ATLAS-571.patch
>
>
> In ATLAS-511, we are introducing mechanisms to handle automated failover and
> also redirecting of requests etc. This JIRA is to test and make necessary
> changes to the AtlasClient class to take advantage of these changes and
> behave in an optimal manner. This implementation could also serve as a model
> for others who are writing their own clients against the Atlas API.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
