jena-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Seaborne (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JENA-5) IndexLARQ is not thread safe
Date Thu, 09 Dec 2010 16:56:00 GMT

    [ 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.


Mime
View raw message