While doing a read I get a TApplicationException: Internal Error processing get_slice.
On Fri, Oct 15, 2010 at 5:49 PM, Jonathan Ellis <jbel...@gmail.com> wrote: > On Fri, Oct 15, 2010 at 2:21 PM, Wayne <wav...@gmail.com> wrote: > > The optimization definitely shaved off some time. Now it is running about > 3x > > CFSTATS reported time. Below are the logs. > > > > There is a ~300ms time frame after the last ResponseVerbHandler prior to > the > > resolver starting. Based on a quorum read the response resolver should > kick > > after 2 reads come in correct? That would mean it waited 500ms before > > starting. Where is this time going? > > It's going to deserialize the replies to see if it has both the data > and enough digests to call resolve(). Then resolve deserializes them > a 2nd time, so there's an easy win there caching the first > deserialize, in the patch attached. (Applies on top of the previous > one, which has been committed to the 0.6 svn branch at > https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.6.) > > > There is still the 3+ second delay between the last 2 entries. Is this > the > > thrift server? > > It's converting the reply from Cassandra's internal representation to > thrift, and sending it to the client. I suspect most of the time is > the actual sending/waiting for the client to read part. Patch 2 also > includes a debug statement after the convert-to-thrift stage to > verify. > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of Riptano, the source for professional Cassandra support > http://riptano.com >
