[
https://issues.apache.org/jira/browse/JENA-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13121944#comment-13121944
]
Andy Seaborne commented on JENA-91:
-----------------------------------
What do you mean "obviously"? Do you have new information?
We have a test case, produced by Paolo, from Talis's testing of TxTDB.
JENA-128 is the root cause of JENA-91 although JENA-91 has had several
other issues in the course of it's life (all addressed). That's why
JENA-128 was resolved as "duplicate".
The test case exhibits the "extremely large buffer" effect (the exact
message and attempted large object creation has been, some while ago,
trapped and dealt with so the message is slightly different nowadays
"Impossibly large object").
Fixing JENA-128 is fixing JENA-91 from all the information and test
cases that we have. TxTDB (as of this earlier this week) has been tested
in the environment that produced the producable JENA-128 and it passed.
If there is still a problem with the current development build, please
create a new entry with details of the setup and a test case.
The one thing we can not solve is that problems with memory mapped files
being deleted on MS Windows. This is unrelated to JENA-91 or JENA-128;
it does break TestTransSystem which deletes on-disk memory mapped files.
You (IBM) do not use mapped mode because of deleting databases and
reusing the space does not work on MS Windows. The TxTDB test suite now
passes on Windows because it creates unique-across-the-test-run directories.
This is a long standing Sun JVM bug from 16-JUL-2002. There various
workarounds on that thread but don't all appear to be reliable; the
last, forcing a GC is a bit dramatic but TDB does now detect it's on
Windows and so, if it works, a contributed patch could be applied.
Other JVMs may vary.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4715154
Andy
> extremely large buffer is being created in ObjectFileStorage
> ------------------------------------------------------------
>
> Key: JENA-91
> URL: https://issues.apache.org/jira/browse/JENA-91
> 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,
> TestTransSystem4.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
> onwards)
> // No - it's in the underlying file storage.
> lengthBuffer.clear() ;
> int x = file.read(lengthBuffer, loc) ;
> if ( x != 4 )
> throw new
> FileException("ObjectFile.read("+loc+")["+filesize+"]["+file.size()+"]:
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
