[
https://issues.apache.org/jira/browse/ACCUMULO-4039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14977219#comment-14977219
]
Adam Fuchs commented on ACCUMULO-4039:
--------------------------------------
The crux of the matter is definitely the unbounded thrift thread pool. I think
the current hand-off to the readahead thread pool works well, and already uses
the future mechanism that would probably be used in a proactor-like approach.
The other issue is that we are forced to have many different threadpools to
avoid potential deadlock the way we do things now, and I'm speculating we might
be able to simplify that to possibly a single threadpool for client services if
we put in the right prioritization.
There's a similar problem on the client side of needing a very large number of
threads for reads in order to reduce latency. That might be improved in a
similar fashion.
I'm glad other people seem to be interested in this topic, too!
> 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)
