[
https://issues.apache.org/jira/browse/ACCUMULO-4039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14977069#comment-14977069
]
Josh Elser commented on ACCUMULO-4039:
--------------------------------------
bq. The current approach of having the separate thread pools makes this easy to
configure and control. QoS needs be be considered.
Except that whole unbounded threadpools part? :)
> 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)
