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/04/02 15:20: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-1.patch

Attaching a patch rebased on top of the committed jiras ATLAS-511 and ATLAS-513.

One change from the previous patch that should be called out:

In an offline discussion with [~shwethags], she provided feedback that making the AtlasClient depend on server side configurations - particularly the list of addresses that form the Atlas server ensemble - is not a right model. The AtlasClient is essentially a stateless system, and a config file with list of server endpoints forms state. This could lead into issues like what happens if one of the server endpoints changes. I find this a very valid argument.

In the new patch, the AtlasClient no longer depends on any HA configuration. Instead, it provides an API for whoever is using it give one or more server URLs for that instance. 
* If only one endpoint is given, it just uses that one endpoint and does not try to determine any active instance etc in the event of failures. However, it adds some configurable retries and sleep intervals.
* If more than one endpoint is given, then it tries to determine the active server url amongst them at startup, and then on any event of failure in reaching the active instance it knows (This is similar to the previous patch I uploaded).

The first instance is a simpler case. If a user has set up a proxy solution in-between to always point to an active instance, then the proxy URL could be the only URL supplied to the client. If an active instance behind the proxy goes down, then the retries would hopefully give time for the proxy to connect to the next active instance transparently.

The second instance is for those environments which do not want this proxy in between, but instead want to rely on a thick client side logic to automatically determine the next active instance.

I modified QuickStart and Hive bridge to accept a comma-separated list of servers and handle them as in the 2nd case. Tested QuickStart as before by bringing down the active instance when it is running, and the failover was handled transparently by the client. 

> 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-1.patch, 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)