[
https://issues.apache.org/jira/browse/HDDS-5954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17453691#comment-17453691
]
István Fajth commented on HDDS-5954:
------------------------------------
Hi [~szetszwo],
thank you for your inputs.
For #1, I meant it is irrelevant for us in the case of EC node access, though
it might not be irrelevant in general for Ozone, as Ozone uses this gRPC client
for read operations. Even if it is done in Ratis, the Ozone read path does not
go through Ratis, and if I am correct, it should not, please correct me if I am
wrong.
#2 is I think something we should look at and understand along with #3 and #4,
as these three together is really about sync/async requests.
#3 I did not know that there is already an ordered async solution in Ratis
specifically for gRPC, I guess you are basically using the same feature of gRPC
that I am proposing to use here... namely to use the same StreamObserver pair
on the client side, and the same thread to process the requests for one client
on the server side I guess though I haven't checked deeply, and not too sure
where exactly I should check both sides of the mechanism, can you give me some
more exact pointers for this in Ratis?
#4 Even though Ratis has an implementation here, as ratis uses the gRPC client
with a different proto definition (as I understood) is it a good idea to try to
generalize this to support multiple proto definitions, different way of
configuring the client, different configuration properties, and somehow bring
the two implementation together with all the existing but separate logic? Also
if we change behaviour and force Ozone reads and EC writes to conform with the
Ratis way, how much would it require to change? I feel that it won't be an easy
ride, how do you see it? As I understand you are proposing something like this.
> EC: Review the TODOs in GRPC Xceiver client and fix them.
> ---------------------------------------------------------
>
> Key: HDDS-5954
> URL: https://issues.apache.org/jira/browse/HDDS-5954
> Project: Apache Ozone
> Issue Type: Sub-task
> Reporter: Uma Maheswara Rao G
> Assignee: István Fajth
> Priority: Major
>
> Currently there are 4 TODO-s in the GRPC client.
> 1. L331 adds a note that we should cache the current leader, so that we can
> go to the leader next time.
> 2. L422 adds a note about sendCommandAsync, which states that it is not
> async. The code on the other hand seems to be returning a CompletableFuture
> instance wrapped inside an XceiverClientReply, though sometimes we wait on
> the future before really returning.
> 3. L452 notes that async requests are served out of order, and this should be
> revisited if we make the API async.
> 4. L483 is connected to #2, and it notes that we should reuse stream
> observers if we are going down the async route
> The latter three requires deeper investigation and understanding, to see how
> we can approach fixing it, and to figure out whether we really need to fix it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
