[
https://issues.apache.org/jira/browse/FLUME-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13570426#comment-13570426
]
Hari Shreedharan commented on FLUME-1896:
-----------------------------------------
So, I see 3 ways around this:
1. Make the process/processBatch methods synchronized/protected by locks, so
only one thread can call these at any point in time - basically enforcing the
user code to manage its own threads - using a pool of threads with a pool of
RpcClients etc - this differs from how Avro RPC works currently.
2. Manage our own clients. Have a list of ThriftClients inside each Rpc Client
(perhaps, the number can be defined by a configuration - maxConnections or
something). "Checkout" a thrift client and wait for it to complete and "check
in it." The only question is the semantics when all connections are checked
out. This allows us to limit the connections. This can potentially have
threading issues.
3. Have a thread local thrift client in the Rpc Client. This is probably the
safest from a threading perspective, but can lead to a high number of open
connections, if the user code uses too many threads - perhaps documenting this
is good enough?
Thoughts?
> Implement Thrift RpcClient
> --------------------------
>
> Key: FLUME-1896
> URL: https://issues.apache.org/jira/browse/FLUME-1896
> Project: Flume
> Issue Type: Sub-task
> Reporter: Hari Shreedharan
> Assignee: Hari Shreedharan
> Attachments: FLUME-1896.patch
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
