See also bug 4884022
To reproduce follow the steps in 4884022. You will see random failures of the search
engine with j2se 1.4.1_x but it appears to work with 1.4.2. Here are some notes from 4884022

I have reproduced this much more reliably on my machine, mwr.
I'm sure it's a jvm bug. It happens with
1.4.1_01-b01 and 1.4.1_02-b06
but the good news is that
1.4.2-b28 (current)
seems to fix it (can't be 100% sure though...)

I heard there was a push for 1.4.2 in Orion. I'm afraid we will have
on-going nasty problems unles we upgrade the jvm.

What's happening is extremely disturbing. I have an object
which starts off life as non-null and then, sooner or later it
becomes null. It is non-deterministic (I'm guessing garbage
collection related).

Eg,
Blah s = new Blah();
use s for a while
suddenly s is null. Oh dear...
I can reproduce this easily on the older jvms.

The Portal Server source code is in ps/search/src/com/sun/portal/search/db/NovaResultSet.java.
At around line 384 we have this code....

SOIF s = null;
try {
AAA s = getDb().fetch(getSToken(), dbkeyval, dbview, 0, getTransaction());
}
catch (RDMException e) {
CSLog.error(1, 1, "Exception when reading db: ", e);
}
BBB if (s == null) {
CSLog.error(1, 1, "Search hit not found in db: " + dbkeyval);
return null; // XXX - exception?
}


if (doHighlights) {
String[] highlightTags = new String[6];
String[] fldHighlightTags = new String[6];
System.arraycopy(hltags, 0, highlightTags, 0, 6);
System.arraycopy(hltags, 6, fldHighlightTags, 0, 6);
buildHighlightInfo(hit, s, view,
highlightTags, defaultPassageContext, defaultPassageSize, defaultMaxPassages,
fldHighlightTags, defaultFldPassageContext, defaultFldPassageSize, defaultFldMaxPassages,
defaultSummaryFromBody);
            // remove non-view attrs since we had to fetch the whole RD from the db to highlight it
            for (Iterator it = s.keySet().iterator(); it.hasNext(); ) {
                if (!view.contains(it.next()))
                    it.remove();
            }
}

// XXX it may be better to only return the score if requested
if (view == null || view.contains("score"))
CCC s.replace("score", "" + Math.round((hit.getScore()*100.0f)));

return s;



At point A an object, s is created.
At point B s is tested for null.
At point C s is randomly null, despite not being null at B.
I have other scenarios which are more easy to test fot that this which require running multiple searches in parallel (perhaps that just speeds up the failure - threading issues are not necessarily implicated)

The allocation of s is associated with parsing a SleepyCat db record. This record is returned by a JNI call to C. The allocation and initialisation of s is entirely in Java however.


###@###.### 2003-07-21