On Wed, 2005-08-24 at 12:10 -0300, [EMAIL PROTECTED] wrote: > Now, while I agree that simple is better, I think QueryParser should > be made thread-safe through the use of a wrapper class (along the > line of what Luc suggested) or by using something other than javacc, > so this is no longer an issue in future lucene versions. > > I caught the error through a load test on a system with low memory > and slow processor, which exacerbates the concurrency issues. > It was a hard to catch bug: even when it showed up the query results > still kinda made sense, because missing or duplicate search terms > don't produce complete garbage. > > I'm a beginner, so I may be missing something big, but if not, many > lucene installations out there may be having this problem without > knowing it.
I think a mention in the Javadoc that QueryParser isn't thread-safe should be enough. Not everything needs to be thread-safe. Are your tests showing the creation of QueryParser objects taking a significant amount of time and/or memory? Just having one QueryParser per thread should be fine, or just create a new one per query. Given that QueryParser is generated by JavaCC, short of changing JavaCC so all its fields are wrapped in ThreadLocals, you'd need to wrap all the methods with synchronized. You could create something like java.util.Collections's synchronizedXXX methods. But my gut feeling is having all parsing go through one synchronized class in a multi-threaded environment will be slower than calling QueryParser's static parse method for each request. IMHO it's better to spot when you need to be careful with threads and handle it appropriately rather trying to make every class you write thread-safe. Check out this article for more: http://www-128.ibm.com/developerworks/java/library/j-threads1.html -- Miles Barr <[EMAIL PROTECTED]> Runtime Collective Ltd. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
