You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@atlas.apache.org by "Hemanth Yamijala (JIRA)" <ji...@apache.org> on 2016/03/30 15:53:25 UTC

[jira] [Updated] (ATLAS-571) Modify Atlas client for necessary changes in context of HA

     [ 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)