I just wondered if any JDBM users had seen this stack trace before, and knew what caused it:
java.lang.NullPointerException
at jdbm.btree.BPage.loadBPage(BPage.java:919)
at jdbm.btree.BPage.access$0(BPage.java:914)
at jdbm.btree.BPage$Browser.getNext(BPage.java:1310)
As you can see, it's when browsing through a BTree. The line of code causing the NPE is the second line of:
BPage<K,V> child = _btree._fetch( recid, this );
child._recid = recid;
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2010-10-12
I looked into this a little more and the only obvious cause I can see for this is where the BaseRecordManager returns null upon fetch(long, Serializer). The CacheRecordManager appears to only return null when the underlying BaseRecordManager returns null.
I am not using an extensible serialiser.
In BaseRecordManager.fetch(long, Serializer) there appears only one way null can be returned:
if( data == null ) { // data.length == 0 ) {
// If you delete a record and then do a fetch, the physMgr identifies
// a zero length byte[] based on the record header. The physMgr has
// been modified to return null instead of data[] so that we can detect
// a deleted record and return null to the application.
//
// Note: The way in which deleted records are detected may be changed
// to permit zero length records, but this test should still be valid.
return null;
}
My suspicion is that this is caused by parallel browsing/removal/restructuring activity. I know there is a warning about this in the Javadoc ("WARNING: If you make structural modifications to the BTree during browsing, you will get inconsistent browing results.") - if this *is* the case (and I will be testing shortly) then hopefully the power of Google will tie up the NPE and above warning keywords for subsequent users!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just wondered if any JDBM users had seen this stack trace before, and knew what caused it:
java.lang.NullPointerException at jdbm.btree.BPage.loadBPage(BPage.java:919) at jdbm.btree.BPage.access$0(BPage.java:914) at jdbm.btree.BPage$Browser.getNext(BPage.java:1310)As you can see, it's when browsing through a BTree. The line of code causing the NPE is the second line of:
I looked into this a little more and the only obvious cause I can see for this is where the BaseRecordManager returns null upon fetch(long, Serializer). The CacheRecordManager appears to only return null when the underlying BaseRecordManager returns null.
I am not using an extensible serialiser.
In BaseRecordManager.fetch(long, Serializer) there appears only one way null can be returned:
if( data == null ) { // data.length == 0 ) { // If you delete a record and then do a fetch, the physMgr identifies // a zero length byte[] based on the record header. The physMgr has // been modified to return null instead of data[] so that we can detect // a deleted record and return null to the application. // // Note: The way in which deleted records are detected may be changed // to permit zero length records, but this test should still be valid. return null; }My suspicion is that this is caused by parallel browsing/removal/restructuring activity. I know there is a warning about this in the Javadoc ("WARNING: If you make structural modifications to the BTree during browsing, you will get inconsistent browing results.") - if this *is* the case (and I will be testing shortly) then hopefully the power of Google will tie up the NPE and above warning keywords for subsequent users!
Yes, the cause of the NullPointerException is very likely due to concurrent access. The behavior is essentially undefined for such case.
alex