[jira] Commented: (JENA-5) IndexLARQ is not thread safe

["Andy Seaborne (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JENA-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969804#action_12969804 ] 

Andy Seaborne commented on JENA-5:
----------------------------------

Brian has also said in previous email:

"""
Thinking about this a bit more, I'm not sure that the ThreadLocal approach is the best one.  It means keeping one parser per thread around for the lifetime of the index.  In my case that would around 150 for the lifetime of the application.  I presume there is not a lot of overhead in setting up a new parser when one is needed.  So maybe better to do that.

And my test case just tests for the specific problem I had.  It needs more work to be a generic test of concurrent queries in LARQ. 
"""

> IndexLARQ is not thread safe
> ----------------------------
>
>                 Key: JENA-5
>                 URL: https://issues.apache.org/jira/browse/JENA-5
>             Project: Jena
>          Issue Type: Bug
>            Reporter: Brian McBride
>         Attachments: IndexLARQ.java, larqConcurrentPatch, TestLARQConcurrent.java
>
>
> Copying a previously sent email:
> I ran into a concurrency problem in LARQ.  When I try to run concurrent queries the Lucene query parser barfs.
> After a bit of digging, I think I understand what is going on.  I was creating  an IndexLARQ and setting that as the global index, then running my queries.  The IndexLARQ constructor constructs a Lucene QueryParser object which it uses for all queries.  Lucene QueryParser objects are not thread safe, so multiple concurrent queries cause the parser the barf.
> I have had a go at patching the HEAD from SVN.  Basically I make the QueryParser object in IndexLARQ ThreadLocal.
> The problem with this is that there is a constructor to IndexLARQ which takes an externally provided QueryParser object and QueryParser is not clonable.  I could replicate the query parser for each thread provided I know its a QueryParser and not a subclass of QueryParser.  If someone passed in a subclass of QueryParser I'd go creating the wrong class of objects as a replica.
> Whilst this scenario is not very likely, since I think the constructor should be deprecated anyway, what I've done is esentially left that constructor alone.  Creating an IndexLARQ with that contructor will continue to construct one that is not thread safe.  The other constructors will construct threadsafe instances.
> Attached are:
> a modified IndexLARQ.java that fixes the problem as I've described.
> TestLARQConcurrent.java - a test case
> larqConcurrentPatch - a patch file that applies the changes
> Oops - Just noticed the license notice on the test case file - you will want to change that if you use this. 
> hmmm - there doesn't seem to be a button here for attaching files.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.