Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: QueryParser not thread-safe
Date: Wed, 24 Aug 2005 11:45:40 +0200
Message-ID: <950FF7DE40C2B64CAF80B564732927E104810B62@exchange.be.bvd>
Thread-Topic: QueryParser not thread-safe
thread-index: AcWoGjStybizD+d3T46gezHgKhDRaAAb8vKg
From: "Vanlerberghe, Luc" <Luc.Vanlerberghe@bvdep.com>
To: <java-user@lucene.apache.org>

Thanks for pointing that out!
I checked the source and QueryParser is indeed not thread-safe (the
presence of local variables like jj_lastpos that are used *during* the
parsing makes this obvious)

Perhaps it should be explicitly mentioned in the javadoc.

The solution I'll probably go for is using ThreadLocal variables
(available since jdk 1.2, but there was a problem in the sun jvm with
deallocation when threads stop until jdk 1.4 or so)

an example (not compiled, nor tested):

public class MyQueryFactory {
    public Query createQuery(String expression) {
        return threadLocalQueryParser.get().parse(expression);
    }
   =20
    private ThreadLocal<QueryParser> threadLocalQueryParser=3Dnew
ThreadLocal<QueryParser>() {
        protected QueryParser initialValue() {
            return new QueryParser("defaultField", new MyAnalyzer());
        }
    };
}

(I used jdk 1.5 generics because the code is clearer, remove the
<QueryParser> and put a few casts where needed if you want this in 1.4
or lower)

initialValue() will be only be called once for every thread that calls
threadLocalQueryParser.get().

See the javadoc for java.lang.ThreadLocal

Luc


-----Original Message-----
From: jian chen [mailto:chenjian1227@gmail.com]=20
Sent: dinsdag 23 augustus 2005 21:38
To: java-user@lucene.apache.org
Subject: Re: QueryParser not thread-safe

Right. My philosophy is that, make it work, then, make it better.=20

Don't waste time on something that you are not sure if it would cause
performance problem.

Jian

On 8/23/05, Paul Elschot <paul.elschot@xs4all.nl> wrote:
> On Tuesday 23 August 2005 19:01, Miles Barr wrote:
> > On Tue, 2005-08-23 at 13:47 -0300, jhandl@fibertel.com.ar wrote:
> > > Hi! I've been having problems with lucene's QueryParser,
apparently it is
> not thread-safe.
> > >
> > > That means I can't parse queries in threads where the queryparser
object
> is created once and reused for each query. If I do, the resulting
queries may
> have all kinds of weird problems, for example missing terms, duplicate
terms,
> etc.
> > >
> > > I don't like the idea of creating a new queryparser for each
query, so I
> am looking for alternatives. Any ideas?
> >
> > Using a non-threadsafe object in a threaded environment is fairly
> > standard in Java, just wrap it in a synchronized block.
> >
> > If you don't want all threads waiting on one query parser, create a
pool
> > of them.
>=20
> Or use one parser per thread.
>=20
> Regards,
> Paul Elschot
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>=20
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org