[
https://issues.apache.org/jira/browse/JENA-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114976#comment-13114976
]
Simon Helsen commented on JENA-91:
----------------------------------
A small update: I adopted the latest ARQ (arq-2.8.9-20110923.125227-37) also in
my internal tests. Although I did find a bug in my own code which accidentally
had TDB run in mapped mode, I noticed that after fixing it and running in
direct mode, I am still seeing a bunch of problems.
1) First of all, I keep seeing early on
18:16:48,649 [jazz.jfs.suspending.indexer.internal.triple] ERROR
com.hp.hpl.jena.tdb.base.block.BlockMgrCache - write: Block in the read
cache
2) The first actual exception (the previous message does not show a stack
trace) is the Quad NPE after a resume
18:17:39,261 [748432540@qtp-535306216-20] INFO com.ibm.team.jfs
- CRJZS5349I Indexing: suspended
18:17:39,497 [748432540@qtp-535306216-20] INFO com.ibm.team.jfs
- CRJZS5348I Indexing: resuming ...
direct
18:17:39,551 [jazz.jfs.resuming.indexer.internal.triple] ERROR com.ibm.team.jfs
- Originating Exception:
java.lang.UnsupportedOperationException: Quad: object cannot be null
at com.hp.hpl.jena.sparql.core.Quad.<init>(Quad.java:50)
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$100(TupleLib.java:32)
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:72)
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:171)
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.ibm.team.jfs.rdf.internal.jenatdbtx.JenaTdbProvider$7.run(JenaTdbProvider.java:1476)
at
com.ibm.team.jfs.rdf.internal.jenatdbtx.JenaTdbProvider$7.run(JenaTdbProvider.java:1)
at
com.ibm.team.jfs.rdf.internal.jenatdbtx.JenaTdbProvider.storeOperation(JenaTdbProvider.java:185)
at
com.ibm.team.jfs.rdf.internal.jenatdbtx.JenaTdbProvider.getLastProcessedTimestamp(JenaTdbProvider.java:1464)
at
com.ibm.team.jfs.rdf.internal.jenatdbtx.JenaRdfService.findLastProcessedTimestamp(JenaRdfService.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at
org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord.invoke(ExportProxyServiceRecord.java:370)
at
org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord.access$0(ExportProxyServiceRecord.java:356)
at
org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord$ExportedServiceInvocationHandler.invoke(ExportProxyServiceRecord.java:56)
at $Proxy296.findLastProcessedTimestamp(Unknown Source)
at
com.ibm.team.jfs.indexing.service.internal.task.TripleIndexAgent.findLastProcessedTimestamp(TripleIndexAgent.java:281)
at
com.ibm.team.jfs.indexing.service.internal.task.AbstractIndexAgent.restoreTimestamp(AbstractIndexAgent.java:924)
at
com.ibm.team.jfs.indexing.service.internal.task.AbstractIndexAgent.initialize(AbstractIndexAgent.java:490)
at
com.ibm.team.jfs.indexing.service.internal.task.LiveIndexAgent.initialize(LiveIndexAgent.java:400)
at
com.ibm.team.jfs.indexing.service.internal.task.LiveIndexAgent.resume(LiveIndexAgent.java:1150)
at
com.ibm.team.jfs.indexing.service.internal.IndexingService$2.run(IndexingService.java:1505)
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.
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
