My vote is for option A. It's generally implied that a major version brings
in major changes (api as well as others), while the minor is, well, minor.
Why should that be broken for lucene? It would become increasingly difficult
for the lucene user community to catch up if they skipped one or two mi
e a bug in the hotspot compiler,
> downgrading to JRE 1.6.0_03, or running Java with -Xbatch (forces up-front
> compilation) or -Xint (disables compilation) works around it.
>
> Can you test either of these and report back? Thanks.
>
> Mike
>
> Gopikrishnan Subramani
[ Sorry if I'm hijacking this thread, if you feel this error is unrelated to
this thread, I'll move this to a separate thread. ]
Even after upgrading to 2.3.1 I'm running into index corruption problems.
I'm posting below the exception that is generated while searching. The stack
trace looks like,
Lucene User... (that's a very generic name to be addressed. if you really
want a phoney name, consider something less generic in this forum), you
probably are using HTML format, try changing it to plain text.
-Gopi
On 6/13/07, Erick Erickson <[EMAIL PROTECTED]> wrote:
Really, check your e-mail
All I could suspect is perhaps you are trying to add documents to an index
that was originally created using Lucene 1.4.3.
If trying to create a fresh index doesn't work, you could send me your
indexer code so I can take a look.
-Gopi
On 12/19/06, JT Kimbell <[EMAIL PROTECTED]> wrote:
Hi,
Did you check POI javadocs? Look for
org.apache.poi.hslf.extractor.PowerPointExtractor. It's one of the most
straightforward classes from POI as far extracting text for indexing is
concerned.
-Gopi
On 9/7/06, Venkateshprasanna <[EMAIL PROTECTED]> wrote:
Is there any filter available for extra
Not sure if it helps, but I have been using Luke (webstart version) from
it's website for quite sometime now for inspecting and manipulating my
indexes built using Lucene 2.0. I may not be a power user of Luke in that
sense, but I haven't found any issues using the basic features.
Gopi
On 8/25/
Erik's has used a space as the field separator. May be you can use a
different field separator that your analyzer won't eat up, so that will
change the token position by 1.
Gopi
On 8/24/06, KEGan <[EMAIL PROTECTED]> wrote:
Erik,
What is generally the reason for indexing both individual fields
AIL PROTECTED]> wrote:
>
> Hi Gopi,
>
> The name of the system property has been changed to
> org.apache.lucene.lockDir and it should be still available.
>
> Thank you,
>
> Koji
>
>
> > -Original Message-
> > From: Gopikrishnan Subramani [mailto:[EMAI
Hello,
With Lucene 1.4.3 I used to use a different lock directory from the default
by setting org.apache.lucene.lockdir system property. But as per
http://lucene.apache.org/java/docs/systemproperties.html this is not
supported in Lucene 1.9 and above. I don't see any equivalent API for
lockDir pro
t's used as a buffer during indexing.
>
> Otis
>
> --- Gopikrishnan Subramani <[EMAIL PROTECTED]> wrote:
>
> > Hello,
> >
> > Is there a way I can control the IO bandwidth utilized by Lucene?
> >
> > Here is my scenario. RAMDirectory is used
Hello,
Is there a way I can control the IO bandwidth utilized by Lucene?
Here is my scenario. RAMDirectory is used to build a in-memory index
and finally the index size approaches a limit, the contents are
flushed to a FSDirectory. The index size could be approximately 512
MB. I'm a bit concerne
12 matches
Mail list logo
