Hi,
Please ignore my last email. Just woke up and wrote the email. After
looking at the luke further it looks like the token is being stored at
index.amin, that is why "amin" wasn't working. Making those changes
that you recommended worked.
I will investigate further why "amin" token i
AUTOMATIC REPLY
LUX is closed until 5th January 2009
-
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
AUTOMATIC REPLY
LUX is closed until 5th January 2009
-
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
Hi Grant
Thank you for looking at the test case. I have updated the
IndexWriter to use UNLIMITED for MaxFieldLength. I tried using
Integer.MAX_VALUE for
Also,
TopDocs topDocs = multiSearcher.search(query,
BooleanQuery.getMaxClauseCount());
strikes me as really odd. Why are you pass
Begin forwarded message:
From: Grant Ingersoll
Date: January 3, 2009 8:19:14 PM EST
To: java-...@lucene.apache.org
Subject: Fwd: Search Test file
Reply-To: java-...@lucene.apache.org
Hi Amin,
I see a couple of issues with your program below, and one that is
the cause of the problem of not
I think it would be nice with little payload modification tool in the
SVN.
karl
2 jan 2009 kl. 23.02 skrev Grant Ingersoll:
I don't think there is any API support for this, but in theory it is
possible, as long as you aren't changing the size. It sounds like
it could work for you si
Hi
I have uploaded to google docs:
url: http://docs.google.com/Doc?id=d77xf5q_0n6hb38fx
Hope this works.
Cheers
Amin
On 3 Jan 2009, at 19:53, Grant Ingersoll wrote:
The mailing list often strips attachments (in fact, I'm surprised
your earlier ones made it through). Perhaps you can put th
The mailing list often strips attachments (in fact, I'm surprised your
earlier ones made it through). Perhaps you can put them up somewhere
for download.
On Jan 3, 2009, at 1:07 PM, Amin Mohammed-Coleman wrote:
Hi again
Sorry I didn't include the WorkItem class! Here is the final test
Hi again
Sorry I didn't include the WorkItem class! Here is the final test
case. Apologies!
On 3 Jan 2009, at 14:02, Grant Ingersoll wrote:
You shouldn't need to call close and optimize after each document.
You also don't need the commit if you are going to immediately close.
Also, can y
Hi
Please find attached a standalone test (inner classes for rtfHandler,
indexing, etc) that shows search not returning expected results. I am
using Lucene 2.4.
Thanks again for the help!
Cheers
Amin
On 3 Jan 2009, at 14:02, Grant Ingersoll wrote:
You shouldn't need to call close and
>
>
> It's very strange that CheckIndex -fix did not resolve the issue. After
> fixing it, if you re-run CheckIndex on the index do you still see that
> original one broken segment present? CheckIndex should have removed
> reference to that one segment.
>
I just ran it again, and it detected the
You shouldn't need to call close and optimize after each document.
You also don't need the commit if you are going to immediately close.
Also, can you send a standalone test that shows the RTF extraction,
the document creation and the indexing code that demonstrates your
issue.
FWIW, and a
Hi
I am currently doing this as the indexer will be called from a upload
action. There is no bulk file processing functioaliry at the moment.
Cheers
Sent from my iPhone
On 3 Jan 2009, at 13:48, Shashi Kant wrote:
Amin,
Are you calling Close & Optimize after every addDocument?
I would
It's remotely possible you hit a JVM bug in the past and that caused the
corruption.
EG there is at least one JVM bug lurking that can affect Lucene (though
apparently with an OS-level fault):
https://issues.apache.org/jira/browse/LUCENE-1342
I don't know much about Amazon's elastic block stor
Amin,
Are you calling Close & Optimize after every addDocument?
I would suggest something like this
try
{
while //this could be your looping through a data reader for example
{
indexWriter.addDocument(document);
}
}
finally
{
commitAndOptimise()
}
HTH
Shashi
> The fastest way to reconstruct the token
> stream would
> be to use the TermFreqVector but if you didn't store it at
> index time
> you would have traverse the inverted index using TermEnum and
> TermPositions in order to pick up the term values and
> positions. This
> can be a rather
Hi again!
I think I may have found the problem but I was wondering if you could
verify:
I have the following for my indexer:
public void add(Document document) {
IndexWriter indexWriter =
IndexWriterFactory.createIndexWriter(getDirectory(), getAnalyzer());
try {
17 matches
Mail list logo
