[
https://issues.apache.org/jira/browse/ACCUMULO-4039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14977108#comment-14977108
]
Josh Elser commented on ACCUMULO-4039:
--------------------------------------
bq. the Thrift threadpools need to be bounded as well....
Yep. This is one of the ugly edges we still have in our RPC system (I was just
talking about this last night), especially when you want to fully understand
the amount of resource utilization. It does, however, make some of the other
points mentioned earlier about deadlocking much easier to deal with. We don't
have to worry about starvation as long as the CPU is eventually working off
threads/tasks. This is something I've looked at elsewhere, and it's a big pain
to avoid deadlock but also being usable for QoS.
Didn't mean to be too snarky in my earlier response. This is just an area that
we can quite definitely improve.
> try out a proactor design pattern for tserver services
> ------------------------------------------------------
>
> Key: ACCUMULO-4039
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4039
> Project: Accumulo
> Issue Type: Improvement
> Components: tserver
> Reporter: Adam Fuchs
> Priority: Minor
>
> For large instances (i.e. lots of clients for a given tserver) we create
> oodles of threads on the tserver. This makes for difficulty in predicting
> performance, memory usage, etc. Moreover, we have operations that recurse,
> like a server querying itself, that we currently solve by having separate
> thread pools for regular table operations and metadata table operations, and
> we "disallow" things like an iterator writing to another table. One
> alternative option would be to switch to a Proactor pattern:
> https://en.wikipedia.org/wiki/Proactor_pattern
> The core of this would be to switch to using a selection set rather than a
> thread per active connection, and then wrap everything in sessions that make
> progress in something like a state model, with states that account for
> asynchronous communications and remote work.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
