[
https://issues.apache.org/jira/browse/HDDS-14379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Andika updated HDDS-14379:
-------------------------------
Description:
This task is to come up with the basic implementation of follower read client
proxy as a baseline before further performance improvements. The idea is to
simply pick a OM node in random (which be leader or follower / listener) and
use it to submit read requests. If the chosen OM node is a follower, the read
requests need to keep sending to that OM node unless the OM is down which
triggers failover. Write requests should be sent to the OM leader directly.
Further improvements such as followers priority or picking OM based on latency,
applied index, etc will be implemented in follow up tasks.
The implementation is to introduce HadoopRpcOMFollowerReadProxyProvider which
wraps
HadoopRpcOMFailoverProxyProvider. FollowerReadProxyProvider tracks a different
currentOmNodeId from HadoopRpcOMFailoverProxyProvider.
FollowerReadInvocationHandler will check whether the request is a read request
(using OmUtils#isReadOnly) and if so forwards it to its current proxy. If it's
a write request, the request if forwarded to HadoopRpcOMFailoverProxyProvider
to be sent to the leader.
So the proxy hierarchy (each with its own InvocationHandler) is
* TracingUtil's proxy (InvocationHandler: TraceAllMethod)
** RetryProxy (InvocationHandler: RetryInvocationHandler)
*** *HadoopRpcOMFollowerReadProxyProvider* (InvocationHandler:
FollowerReadInvocationHandler)
*
**
***
****
***** ProtocolProxy (which is created in
OMFailoverProxyProviderBase#createOMProxy): ProtobufRpcEngine.Invoker
was:
This task is to come up with the basic implementation of follower read client
proxy as a baseline before further performance improvements. The idea is to
simply pick a OM node in random (which be leader or follower / listener) and
use it to submit read requests. If the chosen OM node is a follower, the read
requests need to keep sending to that OM node unless the OM is down which
triggers failover. Write requests should be sent to the OM leader directly.
Further improvements such as adding OM probe logic will be implemented in
follow up tasks.
The implementation is to introduce HadoopRpcOMFollowerReadProxyProvider which
wraps
HadoopRpcOMFailoverProxyProvider. FollowerReadProxyProvider tracks a different
currentOmNodeId from HadoopRpcOMFailoverProxyProvider.
FollowerReadInvocationHandler will check whether the request is a read request
(using OmUtils#isReadOnly) and if so forwards it to its current proxy. If it's
a write request, the request if forwarded to HadoopRpcOMFailoverProxyProvider
to be sent to the leader.
So the proxy hierarchy (each with its own InvocationHandler) is
* TracingUtil's proxy (InvocationHandler: TraceAllMethod)
** RetryProxy (InvocationHandler: RetryInvocationHandler)
*** *HadoopRpcOMFollowerReadProxyProvider* (InvocationHandler:
FollowerReadInvocationHandler)
****
***** ProtocolProxy (which is created in
OMFailoverProxyProviderBase#createOMProxy): ProtobufRpcEngine.Invoker
> Implement basic Hadoop OM client proxy provider to read from followers
> ----------------------------------------------------------------------
>
> Key: HDDS-14379
> URL: https://issues.apache.org/jira/browse/HDDS-14379
> Project: Apache Ozone
> Issue Type: New Feature
> Components: OM HA, Ozone Client
> Reporter: Ivan Andika
> Assignee: Ivan Andika
> Priority: Major
>
> This task is to come up with the basic implementation of follower read client
> proxy as a baseline before further performance improvements. The idea is to
> simply pick a OM node in random (which be leader or follower / listener) and
> use it to submit read requests. If the chosen OM node is a follower, the read
> requests need to keep sending to that OM node unless the OM is down which
> triggers failover. Write requests should be sent to the OM leader directly.
> Further improvements such as followers priority or picking OM based on
> latency, applied index, etc will be implemented in follow up tasks.
> The implementation is to introduce HadoopRpcOMFollowerReadProxyProvider which
> wraps
> HadoopRpcOMFailoverProxyProvider. FollowerReadProxyProvider tracks a
> different currentOmNodeId from HadoopRpcOMFailoverProxyProvider.
> FollowerReadInvocationHandler will check whether the request is a read
> request (using OmUtils#isReadOnly) and if so forwards it to its current
> proxy. If it's a write request, the request if forwarded to
> HadoopRpcOMFailoverProxyProvider to be sent to the leader.
> So the proxy hierarchy (each with its own InvocationHandler) is
> * TracingUtil's proxy (InvocationHandler: TraceAllMethod)
> ** RetryProxy (InvocationHandler: RetryInvocationHandler)
> *** *HadoopRpcOMFollowerReadProxyProvider* (InvocationHandler:
> FollowerReadInvocationHandler)
> *
> **
> ***
> ****
> ***** ProtocolProxy (which is created in
> OMFailoverProxyProviderBase#createOMProxy): ProtobufRpcEngine.Invoker
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
