Simone, >From the documentation, QueryParser is NOT thread-safe. The parser can be re-used, however I have not encountered a negative impact by creating a new instance for each query. I actually don't use the query parser much as I don't want to expose the complete syntax, opting for creating my own queries.
Michael -----Original Message----- From: Simone Chiaretta [mailto:simone.chiare...@gmail.com] Sent: Monday, January 11, 2010 3:12 PM To: lucene-net-user Subject: What is thread safe in Lucene.net? I'm trying to go live with our search engine implementation based on Lucene.net. Unfortunately we have to keep it inside our appdomain in the web application to make it work in shared hosting scenario. But we are getting quite a few problems, so I was wondering if there are some issues with concurrent access: 1 - is the QueryParser thread safe? Can I make it one at the beginning of the times and reuse it in all my queries? or do I've to create one each time? I'm asking because I'm getting strange errors like: ystem.InvalidOperationException: Collection was modified; enumeration operation may not execute. at System.Collections.ArrayList.ArrayListEnumeratorSimple.MoveNext() at Lucene.Net.QueryParsers.QueryParser.Jj_add_error_token(Int32 kind, Int32 pos) at Lucene.Net.QueryParsers.QueryParser.Jj_scan_token(Int32 kind) at Lucene.Net.QueryParsers.QueryParser.Jj_3_1() at Lucene.Net.QueryParsers.QueryParser.Jj_rescan_token() at Lucene.Net.QueryParsers.QueryParser.GenerateParseException() at Lucene.Net.QueryParsers.QueryParser.Jj_consume_token(Int32 kind) at Lucene.Net.QueryParsers.QueryParser.Clause(String field) at Lucene.Net.QueryParsers.QueryParser.Query(String field) at Lucene.Net.QueryParsers.QueryParser.Parse(String query) at Subtext.Framework.Services.SearchEngine.SearchEngineService.Search(Strin g queryString, Int32 max, Int32 blogId, Int32 entryId) Which looks to me like a threading issue. I also got this one: Lucene.Net.QueryParsers.QueryParser+LookaheadSuccess: Error in the application. at Lucene.Net.QueryParsers.QueryParser.Jj_scan_token(Int32 kind) at Lucene.Net.QueryParsers.QueryParser.Jj_3R_2() at Lucene.Net.QueryParsers.QueryParser.Jj_3R_2() at Lucene.Net.QueryParsers.QueryParser.Jj_rescan_token() at Lucene.Net.QueryParsers.QueryParser.Jj_3_1() at Lucene.Net.QueryParsers.QueryParser.GenerateParseException() at Lucene.Net.QueryParsers.QueryParser.Jj_consume_token(Int32 kind) at Lucene.Net.QueryParsers.QueryParser.Jj_consume_token(Int32 kind) at Lucene.Net.QueryParsers.QueryParser.Term(String field) at Lucene.Net.QueryParsers.QueryParser.Clause(String field) at Lucene.Net.QueryParsers.QueryParser.Clause(String field) at Lucene.Net.QueryParsers.QueryParser.Query(String field) at Lucene.Net.QueryParsers.QueryParser.Query(String field) at Lucene.Net.QueryParsers.QueryParser.Parse(String query) at Lucene.Net.QueryParsers.QueryParser.Parse(String query) at Subtext.Framework.Services.SearchEngine.SearchEngineService.Search(Strin g queryString, Int32 max, Int32 blogId, Int32 entryId) And this one: Lucene.Net.QueryParsers.ParseException: Cannot parse 'what is css url': Encountered "what is css url" at line 1, column 0. Was expecting one of: <NOT> ... "+" ... "-" ... "(" ... "*" ... <QUOTED> ... <TERM> ... <PREFIXTERM> ... <WILDTERM> ... "[" ... "{" ... <NUMBER> ... at Lucene.Net.QueryParsers.QueryParser.Parse(String query) Which is fine if I really added an invalid character in the query, but "what is css url" looks to me like it's a valid query. What I'm doing is, to avoid creating a new query parser for each query, to "cache" the same as variable inside the singleton class that holds the search engine. Is this a good approach? or a bad one? (I guess bad since this all seem to be threading issues). Is creating a new query parser for each query a performance problem? Thank you Simone -- Simone Chiaretta Microsoft MVP ASP.NET - ASPInsider Blog: http://codeclimber.net.nz RSS: http://feeds2.feedburner.com/codeclimber twitter: @simonech Any sufficiently advanced technology is indistinguishable from magic "Life is short, play hard"
