OK glad to hear that ;)
Thanks for bringing closure, Ian!
Mike
Ian Connor wrote:
It looks like it was just RAM. I purchased a PHD PCI2 to test all my
RAM from Ultra-X and some modules were just plain bad (some were bad
right away and others needed to warm up before failing - I will
testing a
It looks like it was just RAM. I purchased a PHD PCI2 to test all my
RAM from Ultra-X and some modules were just plain bad (some were bad
right away and others needed to warm up before failing - I will
testing all my RAM from now on).
I have re-index this many times since then and never seen the p
OK gotchya. Please keep us posted one way or another...
Mike
Ian Connor wrote:
Hi Mike,
I am currently ruling out some bad memory modules. Knowing that this
is a index corruption, makes memory corruption more likely. If
replacing RAM does not fix the problem (which I need to do anyway due
t
Hi Mike,
I am currently ruling out some bad memory modules. Knowing that this
is a index corruption, makes memory corruption more likely. If
replacing RAM does not fix the problem (which I need to do anyway due
to segmentation faults), I will package up the crash into a
reproducible scenario.
On
Hi Ian,
I sent this to java-user, but maybe you didn't see it, so let's try
again on solr-user:
It looks like your stored fields file (_X.fdt) is corrupt.
Are you using multiple threads to add docs?
Can you try switching to SerialMergeScheduler to verify it's
reproducible?
When you hi
Ignore that error - I think I installed the Sun JVM incorrectly - this
seems unrelated to the error.
On Fri, Aug 15, 2008 at 9:01 AM, Ian Connor <[EMAIL PROTECTED]> wrote:
> I tried it again (rm -rf /solr/index and post all the docs again) but
> this time, I get the error (I also switched to the S
I tried it again (rm -rf /solr/index and post all the docs again) but
this time, I get the error (I also switched to the Sun JVM to see if
that helped):
15-Aug-08 4:57:08 PM org.apache.solr.core.SolrCore execute
INFO: webapp=/solr path=/update params={} status=500 QTime=4576
15-Aug-08 4:57:08 PM o
We actually have this same exact issue on 5 of our cores. We're just
going to wipe the index and reindex soon, but it isn't actually
causing any problems for us. We can update the index just fine,
there's just no merging going on.
Ours happened when I reloaded all of our cores for a schem
Since this looks like more of a lucene issue, I've replied in
[EMAIL PROTECTED]
-Yonik
On Thu, Aug 14, 2008 at 10:18 PM, Ian Connor <[EMAIL PROTECTED]> wrote:
> I seem to be able to reproduce this very easily and the data is
> medline (so I am sure I can share it if needed with a quick email to
>
I seem to be able to reproduce this very easily and the data is
medline (so I am sure I can share it if needed with a quick email to
check).
- I am using fedora:
%uname -a
Linux ghetto5.projectlounge.com 2.6.23.1-42.fc8 #1 SMP Tue Oct 30
13:18:33 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
%java -vers
Yikes... not good. This shouldn't be due to anything you did wrong
Ian... it looks like a lucene bug.
Some questions:
- what platform are you running on, and what JVM?
- are you using multicore? (I fixed some index locking bugs recently)
- are there any exceptions in the log before this?
- how re
11 matches
Mail list logo
