[
https://issues.apache.org/jira/browse/HDFS-14932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Istvan Fajth resolved HDFS-14932.
---------------------------------
Resolution: Invalid
Sorry I meant to create this one in HDDS project, closing this one, as I can
not move it.
> XCeiverClientManager issues
> ---------------------------
>
> Key: HDFS-14932
> URL: https://issues.apache.org/jira/browse/HDFS-14932
> Project: Hadoop HDFS
> Issue Type: Bug
> Reporter: Istvan Fajth
> Priority: Major
>
> These issues were revealed while reviewing the XCeiverClientManager, and the
> clients.
> - secure clients are not released properly, so the reference counting does
> not work with secure clients
> - even though we have reference counting for the clients, the cache can evict
> and remove client instances with active references, as it is not connected
> with the reference counts
> - isUseRatis, getFactor, getType is not really belonging to this class
> - acquireClient and acquireClientForRead and release methods of the same
> kind, seems to be a bad smell, we might separate the two things, especially
> because reads are using the grpc client while writes are using the ratis
> client as I know
> - pipelines are leaking from the clients themselves, the pipelines are not
> modified in these code paths, but it should be better if we can hide the
> pipeline, and don't serve it for the clients, or if we can serve an immutable
> version
> - ContainerProtocolCalls seems to be something that is extracted to a utility
> class but it may be placed into the client itself, as in all the cases, the
> client is gathered from the XCeiverClientManager, then given to one of
> ContainerProtocolCalls' method, which calls the sendCommandAsync on the
> client which does not seem to be necessary, we can encapsulate all the
> protobuf message creation, and provide response data from the client.
> -ContainerOperationClient acquires the client twice from the
> XCeiverClientManager in the createContainer call, but releases it only once
> - we can try to get rid of some of the synchronization by trying to eliminate
> some of the states in the clients, and the manager, and replace them with
> some polymorphism.
> I will go through this list one by one and will create JIRAs one by one using
> this one as an umbrella JIRA, so that we can create PRs one by one, or if
> needed, we can consolidate the whole thing into one PR at the end but review
> one by one.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
