[ 
https://issues.apache.org/jira/browse/CASSANDRA-6815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13935340#comment-13935340
 ] 

Viktor Kuzmin commented on CASSANDRA-6815:
------------------------------------------

For 2.0 we will be not use off-heap buffers due to cassandra internals - 
cassandra may read from passed ByteBuffer even after succes answer to client 
(after freeing memory).
Also it is not safe to use on-heap buffers. We need to make small patch to 
disruptor server - we need to reallocate data buffer for each message even if 
new message is of equal size as previous.

For 2.1 we do not need any patches.

Also one cosmetic patch for hsha is suggested by me - it will be good to ensure 
that there is no key interests for read/writes between read/write (i.e. when 
we're waiting for message to be processed in threadpool). Without that patch 
there can be 100% cpu usage sometimes in case some data will be still available 
in tcp channel for reading.

> Decided if we want to bring back thrift HSHA in 2.0.7
> -----------------------------------------------------
>
>                 Key: CASSANDRA-6815
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6815
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Sylvain Lebresne
>
> This is the followup of CASSANDRA-6285, to decide what we want to do 
> regarding thrift servers moving forward. My reading of CASSANDRA-6285 
> suggests that the possible options includes:
> # bring back the old HSHA implementation from 1.2 as "hsha" and make the 
> disruptor implementation be "disruptor_hsha".
> # use the new TThreadedSelectorServer from thrift as "hsha", making the 
> disruptor implementation "disruptor_hsha" as above
> # just wait for Pavel to fix the disruptor implementation for off-heap 
> buffers to switch back to that, keeping on-heap buffer until then.
> # keep on-heap buffer for the disruptor implementation and do nothing 
> particular.
> I could be missing some options and we can probably do some mix of those. I 
> don't have a particular opinion to offer on the matter.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to