incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Helsen <>
Subject Re: [jira] [Commented] (JENA-91) extremely large buffer is being created in ObjectFileStorage
Date Mon, 19 Sep 2011 13:17:31 GMT
btw, this is why we (at IBM) have never adopted mapped mode (a.o. 
reasons). We have to support Windows and we need the ability to clear a 
directory and reuse it, so...

But see my comments in the work item, even in direct mode, we have 
problems on Windows


"Andy Seaborne (JIRA)" <>
09/17/2011 05:27 PM
[jira] [Commented] (JENA-91) extremely large buffer is being created in 



Andy Seaborne commented on JENA-91:

JENA-115 shows that reusing directories is problematic on MS windows when 
using mapped mode.  TestTransSystem works for direct mode but not for 
mapped mode for me.

The error is that existing files don't get deleted so later code see 
inconsistent junk.

TestTransSystem reuses directories via static clean().

Simon - do you, in your internal tests, reuse directories and delete index 

> extremely large buffer is being created in ObjectFileStorage
> ------------------------------------------------------------
>                 Key: JENA-91
>                 URL:
>             Project: Jena
>          Issue Type: Bug
>          Components: TDB
>            Reporter: Simon Helsen
>            Assignee: Andy Seaborne
>            Priority: Critical
>         Attachments: JENA-91_NodeTableTrans_r1159121.patch, 
TestTransSystem.patch, TestTransSystem2.patch, TestTransSystem3.patch, 
> I tried to debug the OME and check why a bytebuffer is causing my native 
memory to explode in almost no time. It all seems to happen in this bit of 
code in com.hp.hpl.jena.tdb.base.objectfile.ObjectFileStorage (lines 243 
>   // No - it's in the underlying file storage.
>         lengthBuffer.clear() ;
>         int x =, loc) ;
>         if ( x != 4 )
>             throw new 
Failed to read the length : got "+x+" bytes") ;
>         int len = lengthBuffer.getInt(0) ;
>         ByteBuffer bb = ByteBuffer.allocate(len) ;
> My debugger shows that x==4. It also shows the lengthBuffer has the 
following content: [111, 110, 61, 95]. This amounts to the value of 
len=1869495647, which is rather a lot :-) Obviously, the next statement 
(ByteBuffer.allocate) causes the OME.

This message is automatically generated by JIRA.
For more information on JIRA, see:


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message