headers
Scott Smith | 19 May 2013 20:50

classic.QueryParser - bug or new behavior?

I just upgraded from lucene 4.1 to 4.2.1.  We believe we are seeing some different behavior.

I'm using org.apache.lucene.queryparser.classic.QueryParser.  If I pass the string
"20110920/EXPIRED" (w/o quotes) to the parser, I get:

org.apache.lucene.queryparser.classic.ParseException: Cannot parse '20110920/EXPIRED': Lexical
error at line 1, column 17.  Encountered: <EOF> after : "/EXPIRED"
       at org.apache.lucene.queryparser.classic.QueryParserBase.parse(QueryParserBase.java:131)

We believe this used to work.

I tried googling for this and found something that said I should use QueryParser.escape() on the string
before passing it to the parser.  However, that seems to break phrase queries (e.g., "John Smith" - with the
quotes; I assume it's escaping the double-quotes and doesn't realize it's a phrase).

Since it is a forward slash, I'm confused why it would need escaping of any of the characters in the string
with the "/EXPIRED".

Has anyone seen this?

Scott
Permalink | Reply | 0 comments |
headers
John Wang | 17 May 2013 21:07
Picon
Gravatar

command line lucene

Hi folks:

     Sorry about the cross-post.

      Luke is awesome, but sometimes you only have command line access to
your production boxes. So I wrote CLue, a command line lucene interface in
the likes of Luke:

      Please take a look and collaborators wanted :)

https://github.com/javasoze/clue

Thanks

-John
Permalink | Reply | 1 comment |
headers
fifi | 17 May 2013 15:11
Picon
Favicon

ERROR help me please ,org.apache.lucene.search.IndexSearcher.<init>(Ljava/lang/String;)V

please,how I can solve this error?

Exception in thread "main" java.lang.NoSuchMethodError:
org.apache.lucene.search.IndexSearcher.<init>(Ljava/lang/String;)V 

--
View this message in context: http://lucene.472066.n3.nabble.com/ERROR-help-me-please-org-apache-lucene-search-IndexSearcher-init-Ljava-lang-String-V-tp4064195.html
Sent from the Lucene - Java Users mailing list archive at Nabble.com.
Permalink | Reply | 2 comments |
headers
Hu Jing | 17 May 2013 11:10
Picon

how to get max value of a long field?

I want to know the max value of a long field.
I read lucene api , but don't find any api about this?
does someone can supply any hits about how to implement this.

thanks very much.
Permalink | Reply | 6 comments |
headers
Geoff Cooney | 16 May 2013 16:45
Picon

CorruptIndexException when opening Index during first commit

Hi,

We're occasionally seeing a CorruptIndexException when a searcher is opened
on a new index.

When we see the exception, it looks like what is happening is that the
searcher is opening the index after prepareCommit for segments_1 but before
the commit is completed.  Because there is no prior commit to fall back to,
lucene throws the CorruptIndexException.  Does this sounds feasible and is
it a bug?  My expectation is that lucene would treat the index as
nonexistent until the first commit is completed.

We're running lucene 3.5.

Cheers,
Geoff
Permalink | Reply | 3 comments |
headers
raj | 16 May 2013 07:44
Picon

Faceted search using Lucene 4.3

Hi,

I was checking on Lucene Faceted search and need some guidance.
http://lucene.apache.org/core/4_3_0/facet/org/apache/lucene/facet/doc-files/userguide.html#facet_indexingmentions
about

    DocumentBuilder categoryDocBuilder = new CategoryDocumentBuilder(taxo);

But I am unable to find DocumentBuilder and CategoryDocumentBuilder classes
in lucene-facet-4.3.0.jar. Most of the online tutorials that I could find
also mentions the same steps as in official doc
These are present in an old version -
http://lucene.apache.org/core/old_versioned_docs/versions/3_4_0/api/contrib-facet/org/apache/lucene/DocumentBuilder.html

What are the equivalent ones in 4.3? Or any help in getting this
implemented in 4.3?

Thanks,
Rajesh
Permalink | Reply | 2 comments |
headers
Vitaly Funstein | 15 May 2013 22:37
Picon

Toggling compression for stored fields

Is it possible to have a mix of compressed and uncompressed documents
within a single index? That is, can I load an index created with Lucene 4.0
into 4.1 and defer the decision of whether or not to use
CompressingStoredFieldsFormat until a later time, or even go back and forth
between compressed and uncompressed codecs, if needed? I thought at first
the answer would be an unequivocal "no", but then how would one migrate
data from 4.0 to 4.1 without a full reindex?
Permalink | Reply | 7 comments |
headers
Sergiusz Urbaniak | 15 May 2013 17:50
Picon

Fwd: Deadlock in DocumentsWriterFlushControl

Hi all,

We have an obvious deadlock between a "MaybeRefreshIndexJob" thread
calling ReferenceManager.maybeRefresh(ReferenceManager.java:204) and a
"RebuildIndexJob" thread calling
IndexWriter.deleteAll(IndexWriter.java:2065).

Lucene tries to flush in the "MaybeRefreshIndexJob" thread while
simultaneously waiting for the flush in the "RebuildIndexJob" thread
deadlocked by the intrinsic lock on the IndexWriter instance.

May this be a bug or is it wrong usage? We are not explicitly locking
on the IndexWriter instance (following the documentation).

Thread-Dump:

"Thread - 1" daemon prio=10 tid=0x00007f8fe4006000 nid=0x1ac2 waiting
for monitor entry [0x00007f8fa7bf7000]
   java.lang.Thread.State: BLOCKED (on object monitor)
at
org.apache.lucene.index.IndexWriter.useCompoundFile(IndexWriter.java:2223)
- waiting to lock &lt;0x00000000f1c00438&gt; (a
org.apache.lucene.index.IndexWriter)
at
org.apache.lucene.index.DocumentsWriterPerThread.sealFlushedSegment(DocumentsWriterPerThread.java:563)
at
org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:533)
at org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:422)
at
org.apache.lucene.index.DocumentsWriter.flushAllThreads(DocumentsWriter.java:559)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Hendrik Lücke-Tieke | 15 May 2013 06:46

AW: lucene and mongodb

Hi mate,

we did that (w/ lucene 3.6)  and reconsidered it as "very bad idea" afterwards. Why? (a) out of the box,
mongodb does only 16-mb files. Lucene files grow (much) larger than that. (b) lucene indices seem highly
optimized to create good performance when reading them from disk. A layer like gridfs is likely to destroy
all that handcrafted performance benefits.

So you can strore it in mongodb, but there are better ways (e.g. using solr as store instead of mongo)

Kind regards,
Hendrik

-----Ursprüngliche Nachricht-----
Von: Rider Carrion Cleger [mailto:rider.carrion <at> gmail.com] 
Gesendet: Dienstag, 14. Mai 2013 10:36
An: java-user-info <at> lucene.apache.org; java-user-faq <at> lucene.apache.org; java-user <at> lucene.apache.org
Betreff: lucene and mongodb

Hi team,
I'm working with apache lucene 4.2.1 and I would like to store lucene index in a NoSql database.
So my questions are,
- Can I store the lucene index in a mongodb database ?

thanks you team!
Permalink | Reply | 2 comments |
headers
G B | 14 May 2013 22:19
Picon

IndexReader doc method performance troubles

Hi there,
We've been having troubles with performance regarding IndexReader's *
document<http://lucene.apache.org/core/4_1_0/core/org/apache/lucene/index/IndexReader.html#document(int)>
*(int docID) method.

In summary:
Why would the *document<http://lucene.apache.org/core/4_1_0/core/org/apache/lucene/index/IndexReader.html#document(int)>
*(int docID) take a few seconds? For some docIds it takes a millisecond and
for some it takes up to a few seconds whereas it used to consistenly take a
millisecond  for each doc fetched.

In depth:
We have a set of 6 app servers and each serve around a million requests per
day.
Specs for these app servers are: Ubuntu x86_64 GNU/Linux 8GB RAM, Java 6
with an Xmx setting of 4 GB. Using Lucene 4.1. Current index size is 2.1 GB.

We've started using Lucene more extensively in the last 6 months, our index
size used be ~ 1.5 GB and back then we had no problems.
Recently we acquired more data and the index size jumped to 2.1 GB. When we
pushed this new data to production first we had Out of Memory
org.apache.lucene.search.FieldCacheImpl$Cache.get(FieldCacheImpl.java:248)
exception. The recommendation was to increase the memory so we upped the
Xmx setting 4GB but then we had the
https://issues.apache.org/jira/browse/LUCENE-1566 (Lucene bug caused by the
JVM). Increasing the memory of the servers to 8GB seems to resolve this
problem. Now, the system is stable and no more of those exceptions but the
response times of Lucene searches increased by 50%. Debugging the issue,  I
realized that IndexReader's doc is taking an insane amount of time. Used to
be a ms each but now it can take a few seconds to fetch a single doc. Is
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tamer Gür | 14 May 2013 16:34
Picon
Picon
Favicon

unindexed field boost

Hello all,

i was wondering why unindexed fields can't be boosted compare to lucene 3.
since these fields are still in the score calculation when i checked the 
score explanation. Is there any clean way to pass this?

Thanks
Tamer
Permalink | Reply | 1 comment |

Gmane