I'm writing an RPC service that could potentially have very high latency (blocking, essentially). So I'm trying to figure out which if any of the Java server choices are good for handling this sort of thing while still scaling to a high QPS.
The best (and only) resource I found that enumerates all of the server options for Java is https://github.com/m1ch1/mapkeeper/wiki/Thrift-Java-Servers-Compared. From this, it would seem like my options are THsHaServer, TThreadedSelectorServer, and TThreadPoolServer. All of these share the same idea of accept a connection and farm it out to a worker in a thread pool. The downside seems to be that if there's a high QPS of big-latency requests, the worker threads can get tied up. Thus, I was wondering if there would be any interest in the development of a new server type, TQuasarServer, which would utilize Quasar fibers as the concurrency primitive for workers and therefore (at least theoretically[1]) not be limited via a worker thread pool. If I was to develop it, would such a patch be likely to be accepted into Thrift, given that it introduces that kind of optional external dependency? Thanks, -- Morgon [1] It's not clear at what latency breakpoint you would get gains in throughput; I'd obviously need to measure this.
