[
https://issues.apache.org/jira/browse/CALCITE-5581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704099#comment-17704099
]
Vaibhav Joshi edited comment on CALCITE-5581 at 3/23/23 11:54 AM:
------------------------------------------------------------------
[~stoty]
This is good suggestion. But I am seeing some challenges here. We need to
consider few aspects.
*Handling failed hosts*
Detecting failures should be easy(I believe try-catch block in connect method),
we can even try to maintain some global list of failed hosts.
But identifying and categorizing failed hosts will be challenging.
* Connection can fail due to transient or non-transient failures. We need to
blacklist only hosts with non-transient failures. Retry mechanism should handle
transient failures. Challenge here is, how can we identify and categorize
failures? Can we safely rely on HTTP error (e.g. 500 and 503)? Considering
that fact that we can have different client implementation, is this a correct
assumption?
* If we some above problem, we can maintain some TTL cache for failed host
lookup. TTL cache will make sure that host is not blocked forever. We can keep
TTL cache configurable. But this will impact performance i.e. some CPU and
memory resource will be consumed to make our client smarter.
*Internal Retries for the failures*
Yes this can be done. I believe we are talking about simple retries e.g. N
retries at interval of M sec, with N and M as configurable parameters. Backoff
retries will make our client bulky so we should keep it out of scope.
But it's again tied to nature of failure (transient or non transient). Few
points discussed above are applicable.
In first cut implementation we can keep it simple and retry all failures ( say
6 retries at interval of 10 seconds by default).
was (Author: JIRAUSER291813):
[~stoty]
This is good suggestion. But I am seeing some challenges here. We need to
consider few aspects.
*Handling failed hosts*
Detecting failures should be easy(I believe try-catch block in connect method),
we can even try to maintain some global list of failed hosts.
But identifying and categorizing failed hosts will be challenging.
* Connection can fail due to transient or non-transient failures. We need to
blacklist only hosts with non-transient failures. Retry mechanism should handle
transient failures. Challenge here is, how can we identify and categorize
failures? Can we safely rely on HTTP error (e.g. 500 and 503)? Considering
that fact that we can have different client implementation, is this a correct
assumption?
* If we some above problem, we can maintain some TTL cache for failed host
lookup. TTL cache will make sure that host is not blocked forever. We can keep
TTL cache configurable. But this will impact performance i.e. some CPU and
memory resource will be consumed to make our client smarter.
*Internal Retries for the failures*
Yes this can be done. I believe we are talking about simple retries e.g. N
retries at interval of M sec, with N and M as configurable parameters. Backoff
retries will make our client bulky so we should keep it out of scope.
But it's again tied to nature of failure (transient or non transient). Few
points discussed above are applicable.
In first cut implementation we can keep it simple and retry all failures ( 3
retries at interval of 10 seconds by default).
> Implement Basic client side load balancing in Avatica Driver
> ------------------------------------------------------------
>
> Key: CALCITE-5581
> URL: https://issues.apache.org/jira/browse/CALCITE-5581
> Project: Calcite
> Issue Type: New Feature
> Components: avatica
> Affects Versions: 1.33.0
> Reporter: Vaibhav Joshi
> Assignee: Vaibhav Joshi
> Priority: Major
> Labels: pull-request-available
> Attachments: Avatica Basic client side load balancing.docx
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Implement mechanism to support Client side load balancing by configuring
> connection properties for load balancing
> {code:java}
> jdbc:phoenix:thin:
> url=https://<host>:<port>;
> serialization=PROTOBUF;
> authentication=BASIC;
> avatica_user=<userName>;
> avatica_password=<userPw>
> useClientSideLB: [true/false]
> lbStrategy: [RandomDistribution/Sequential/RoundRobin]
> lbURLs: <comma separated URls e.g. URL1, URL2,URL3,...URLn> {code}
> Client should connect to any of the URLs specified in lbURLs ( depending on
> LB strategy selected). Please refer to [^Avatica Basic client side load
> balancing.docx]for more details
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
