[ 
https://issues.apache.org/jira/browse/JENA-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Helsen reopened JENA-91:
------------------------------


It seems that the problem is not quite resolved. I have attached a patch which 
can be applied to TestTransSystem and which seems to produce the following 
exception (this is all with the latest August 31 snapshot)

START (disk, 100 iterations)
000: ..java.lang.UnsupportedOperationException: Quad: predicate cannot be null
        at com.hp.hpl.jena.sparql.core.Quad.<init>(Quad.java:49)
        at com.hp.hpl.jena.tdb.lib.TupleLib.quad(TupleLib.java:127)
        at com.hp.hpl.jena.tdb.lib.TupleLib.quad(TupleLib.java:118)
        at com.hp.hpl.jena.tdb.lib.TupleLib.access$1(TupleLib.java:114)
        at com.hp.hpl.jena.tdb.lib.TupleLib$4.convert(TupleLib.java:76)
        at com.hp.hpl.jena.tdb.lib.TupleLib$4.convert(TupleLib.java:1)
        at org.openjena.atlas.iterator.Iter$4.next(Iter.java:268)
        at 
com.hp.hpl.jena.tdb.store.GraphTDBBase$ProjectQuadsToTriples.next(GraphTDBBase.java:183)
        at 
com.hp.hpl.jena.tdb.store.GraphTDBBase$ProjectQuadsToTriples.next(GraphTDBBase.java:1)
        at 
com.hp.hpl.jena.util.iterator.WrappedIterator.next(WrappedIterator.java:68)
        at com.hp.hpl.jena.util.iterator.Map1Iterator.next(Map1Iterator.java:35)
        at 
com.hp.hpl.jena.util.iterator.WrappedIterator.next(WrappedIterator.java:68)
        at 
com.hp.hpl.jena.rdf.model.impl.StmtIteratorImpl.next(StmtIteratorImpl.java:33)
        at 
com.hp.hpl.jena.rdf.model.impl.StmtIteratorImpl.next(StmtIteratorImpl.java:21)
        at 
com.hp.hpl.jena.tdb.transaction.TestTransSystem.readModel(TestTransSystem.java:446)
        at 
com.hp.hpl.jena.tdb.transaction.TestTransSystem.access$1(TestTransSystem.java:438)
        at 
com.hp.hpl.jena.tdb.transaction.TestTransSystem$Reader.call(TestTransSystem.java:163)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314)
        at java.util.concurrent.FutureTask.run(FutureTask.java:149)
        at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:897)
        at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:919)
        at java.lang.Thread.run(Thread.java:736)

> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to