Hi all, I just realised that the binary protocol is the low-level thrift api that I was originally using (Cassandra.Client>> get / insert ...). How can a prepared statement be called through the thrift api (i.e. not the cql methods)?
Cheers, Stuart On Tue, Apr 23, 2013 at 11:48 AM, Stuart Broad <stu...@moogsoft.com> wrote: > Hi Sylvain, > > Thanks for your response. I am handling the > 'PreparedQueryNotFoundException' more for the case of a cassandra re-start > (rather then expecting to build 100000 statements). > > I am not familiar with the binary protocol - which class/methods should I > look at? > > Regards, > > Stuart > > > > On Tue, Apr 23, 2013 at 11:29 AM, Sylvain Lebresne > <sylv...@datastax.com>wrote: > >> In thrift, a lot of exceptions (like PreparedQueryNotFoundException) are >> simply returned as InvalidRequestException. The reason for that was a mix >> of not wanting to change the thrift API too much and because we didn't knew >> how to return a lot of different exception with thrift without making it >> horrible to work with. So you'll probably have to parse strings here indeed. >> >> This will be cleaner/less fragile if you use the binary protocol as >> exceptions are more fined grained there. >> >> Though taking a step back (and without saying that you shouldn't handle >> the case where a query is not prepared on the node you contact), if you're >> really considering preparing more than 100000 statements, I'd suggest that >> it might be worth benchmarking whether using prepared statements in your >> case is really going to be worth the trouble. Just saying. >> >> -- >> Sylvain >> >> >> >> On Tue, Apr 23, 2013 at 12:14 PM, Stuart Broad <stu...@moogsoft.com>wrote: >> >>> Hi Sorin, >>> >>> The PreparedQueryNotFoundException is not thrown from >>> Cassandra.Client>>execute_prepared_cql3_query method. I created some >>> prepared statements and then re-started cassandra and received the >>> following exception: >>> >>> InvalidRequestException(why: Prepared query with ID 1124421588 not found >>> (either the query was not prepared on this host (maybe the host has been >>> restarted?) or you have prepared more than 100000 queries and queries >>> 1124421588 has been evicted from the internal cache)) >>> >>> The best I have been able to come up with is the following: >>> >>> try { >>> client.execute_prepared_cql3_query(psId, bindValues, ..); >>> } catch (InvalidRequestException invEx) { >>> String why = invEx.getWhy(); >>> CLogger.logger().warning(why); >>> if(why.startsWith("Prepared query with ID")) { >>> rebuildPreparedStatement(preparedStatement); >>> client.execute_prepared_cql3_query(psId, bindValues, >>> ..); >>> } else { >>> throw invEx; >>> } >>> } >>> >>> Obviously this is pretty fragile and would break if the cassandra >>> message was changed...but it least it works for now! >>> >>> Cheers, >>> >>> Stuart >>> >>> >>> On Sun, Apr 21, 2013 at 11:51 AM, Sorin Manolache <sor...@gmail.com>wrote: >>> >>>> On 2013-04-19 13:57, Stuart Broad wrote: >>>> >>>>> Hi, >>>>> >>>>> I am using Cassandra.Client >>>>> prepare_cql3_query/execute_**prepared_cql3_query to create and run >>>>> some >>>>> prepared statements. It is working well but I am unclear as to how >>>>> long >>>>> the server side 'caches' the prepared statements. Should a prepared >>>>> statement be prepared for every new Cassandra.Client? Based on my >>>>> limited testing it seems like I can create some prepared statements in >>>>> one Cassandra.Client and use in another but I am not sure how >>>>> reliable/lasting this is i.e. If I called the prepared statement again >>>>> the next day would it still exist? What about if cassandra was >>>>> re-started? >>>>> >>>>> _Background:_ >>>>> >>>>> I am creating prepared statements for batch updates of pre-defined >>>>> lengths (e.g. 10000, 1000, 500, 250, 50, 10, 1) and wanted to know if >>>>> these could just be set up once. We felt that using the prepared >>>>> statements was easier than escaping values within a CQL statement and >>>>> probably more performant. >>>>> >>>>> Thanks in advance for your help. >>>>> >>>>> >>>> I've looked in Cassandra's code (v1.2.3). The cache of prepared >>>> statements has a size of 100,000. So if you prepare more than 100 thousand >>>> statements, the least recently used ones will vanish. You'll get the >>>> exception PreparedQueryNotFoundException**, code 0x2500. >>>> >>>> Regards, >>>> Sorin >>>> >>>> >>>> >>> >> >