Then you're probably using a client incompatible with the server version you're using.
On Mon, Apr 12, 2010 at 10:24 AM, Lee Parker <l...@socialagency.com> wrote: > If the connections are being made by individual PHP processes running from > the command line, they shouldn't be using the same connection. Should my > code close the connections after each query and open a new one? > Here is the flow of what is happening when we get the error: > 1. Get a set of items from remote API > 2. Insert all of the items into the items CF. (usually anywhere from 2 - 200 > items) > 3. Query the correct index for all entries within a particular time frame > (which is determined by the timeframe of the results of step 1) > 4. Compare keys in index to keys of items inserted in step 2. > 5. Insert new index columns for items which aren't already in the index. > I am getting the "unknown result" error during step 3. > Lee > > On Mon, Apr 12, 2010 at 10:05 AM, Jonathan Ellis <jbel...@gmail.com> wrote: >> >> unknown result means thrift is badly confused. You will get this when >> using the same thrift connection from multiple threads, for instance. >> >> On Mon, Apr 12, 2010 at 10:02 AM, Lee Parker <l...@socialagency.com> wrote: >> > I am a newbie with Cassandra. We are currently migrating a large amount >> > of >> > data out of MySQL into Cassandra. I have two ColumnFamilies. One >> > contains >> > one row per item and each item has roughly 12 columns. These are items >> > from >> > REST APIs like the Twitter API. Then I have a second ColumnFamily with >> > very >> > large rows and TimeUUID column names which contain the key of the items >> > in >> > the other ColumnFamily. So one ColumnFamily has lots of rows with a low >> > number of columns per row, and the other has relatively few rows with a >> > large (~500k) columns per row. >> > I am getting rather frequent errors with "unknown result" from get_slice >> > and >> > multiget_slice calls from the index ColumnFamily. I am using Pandra for >> > the >> > calls. I can see that this is a generic exception thrown by the >> > Cassandra >> > Thrift package when it doesn't know what else to say. Is there a way to >> > actually see what the result was in a more raw form from the Thrift >> > protocol? >> > One thought I had on why this is happening is that my results might be >> > larger than the configuration settings. Does anyone have any good ideas >> > on >> > how to calculate what the ideal values of SlicedBufferSizeInKB >> > and ColumnIndexSizeInKB should be? If these are too low, would i get a >> > more >> > descriptive error? >> > Lee Parker > >
