[
https://issues.apache.org/jira/browse/CASSANDRA-5239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14380520#comment-14380520
]
Ariel Weisberg commented on CASSANDRA-5239:
-------------------------------------------
Sorry about resurrecting this I just happened to be passing by.
By incremental processing are you talking about something like streaming a
large result set?
Guava listenable futures might be insufficient for that, but we could roll our
own for asynchronous activities that have that kind of lifecycle. That is
plumbing we would have to build in one form or another either way. It wouldn't
be particular useful outside of using a familiar idiom because all the existing
code that works with Futures would materialize the entire thing on get().
Starting with plain listenable futures and then retrofitting a new kind of
future doesn't seem like it's much better/worse then what is there from an
incremental processing implementation perspective. It might even just be
something like an async iterator of plain listenable futures.
> Asynchronous (non-blocking) StorageProxy
> ----------------------------------------
>
> Key: CASSANDRA-5239
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5239
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.0 beta 1
> Reporter: Vijay
> Labels: performance
> Fix For: 3.0
>
>
> Problem Statement:
> Currently we have "rpc_min_threads, rpc_max_threads"/
> "native_transport_min_threads/native_transport_max_threads" all of the
> threads in the TPE are blocking and takes resources, the threads are mostly
> sleeping. Increasing the Context switch costs.
> Details:
> We should change StorageProxy methods to provide a callback which contains
> the location where the results has to be written. When the response arrive
> StorageProxy callback can write the results directly into the connection.
> Timeouts can be handled in the same way.
> Fixing Netty should be trivial with some refactor in the storage proxy
> (currently it is one method call for sending the request and waiting) we need
> callback.
> Fixing Thrift may be harder because thrift calls the method and expects a
> return value. We might need to write a custom Codec on Netty for thrift
> support, which can potentially do callbacks (A Custom codec may be similar to
> http://engineering.twitter.com/2011/04/twitter-search-is-now-3x-faster_1656.html
> but we dont know details about it). Another option is to update thrift to
> have a callback.
> FYI, The motivation for this ticket is from another project which i am
> working on with similar Proxy (blocking Netty transport) and making it Async
> gave us 2x throughput improvement.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
