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 <[email protected]>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 <[email protected]>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 <[email protected]>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 >>> >>> >>> >> >
