[ https://issues.apache.org/jira/browse/ACCUMULO-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15148554#comment-15148554 ]
marco polo commented on ACCUMULO-3477: -------------------------------------- I began using TThreadedSelectorServer this weekend for a similar use case and it works exceptionally well. What worked really well was extending TThreadedSelectorServer, creating threads for ops I knew would be fast, and leaving things like a "startScan" or a "continue(Multi)Scan" handler to the thread pool. It required more coupling of the server to the processor/handler, but ultimately worked really well. > Evaluate use of TThreadedSelectorServer > --------------------------------------- > > Key: ACCUMULO-3477 > URL: https://issues.apache.org/jira/browse/ACCUMULO-3477 > Project: Accumulo > Issue Type: New Feature > Components: master, tserver > Reporter: Josh Elser > Fix For: 1.8.0 > > > I re-read > https://github.com/m1ch1/mapkeeper/wiki/Thrift-Java-Servers-Compared today, > specifically the section on thshaserver vs tthreadedselectorserver. > {quote} > TThreadedSelectorServer performs better than THsHaServer when the network io > is the bottleneck > {quote} > This made me think that in read-heavy environments, we may benefit from using > the TThreadedSelectorServer instead of the THsHaServer. I know from previous > experiments that we can spend a significant amount of time for a query just > sending bytes over the wire from server(s) to a client. Improving this case > may have benefit. > Like THsHaServer, TThreadedSelectorServer relies on the TFramedTransport, so > this is only relevant for non-SSL and non-SASL cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)