[ 
https://issues.apache.org/jira/browse/JENA-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13148036#comment-13148036
 ] 

Simon Helsen commented on JENA-143:
-----------------------------------

After the fix for JENA-131, there still seems to be an issue, but it is not 
100% identical in the sense that I don't see the warnings of the type

WARN hpl.jena.sparql.engine.iterator.QueryIteratorCheck - Open iterator: 
QueryIterFilterExpr/37159 

anymore. but I did get

16:39:00,060 [jazz.jfs.indexer.jfs_tests_default_consumer_name.triple] ERROR 
com.ibm.team.jfs                                    - Originating Exception:
com.hp.hpl.jena.tdb.base.file.FileException: 
ObjectFile.read(8023)[83229][83229]: Impossibly large object : 591743342 bytes
        at 
com.hp.hpl.jena.tdb.base.objectfile.ObjectFileStorage.read(ObjectFileStorage.java:294)
        at 
com.hp.hpl.jena.tdb.base.objectfile.ObjectFileStorage$ObjectIterator.next(ObjectFileStorage.java:409)
        at 
com.hp.hpl.jena.tdb.base.objectfile.ObjectFileStorage$ObjectIterator.next(ObjectFileStorage.java:384)
        at org.openjena.atlas.iterator.Iter$4.next(Iter.java:293)
        at 
com.hp.hpl.jena.tdb.transaction.NodeTableTrans.append(NodeTableTrans.java:171)
        at 
com.hp.hpl.jena.tdb.transaction.NodeTableTrans.writeNodeJournal(NodeTableTrans.java:210)
        at 
com.hp.hpl.jena.tdb.transaction.NodeTableTrans.commitPrepare(NodeTableTrans.java:190)
        at 
com.hp.hpl.jena.tdb.transaction.Transaction.prepare(Transaction.java:109)
        at 
com.hp.hpl.jena.tdb.transaction.Transaction.commit(Transaction.java:93)
        at com.hp.hpl.jena.tdb.DatasetGraphTxn.commit(DatasetGraphTxn.java:38)
        at 
com.ibm.team.jfs.rdf.internal.jena.tdb.JenaTdbTxProvider.storeOperation(JenaTdbTxProvider.java:321)
        <snip>
and

16:39:00,064 [jazz.jfs.indexer.jfs_tests_default_consumer_name.triple] ERROR 
com.ibm.team.jfs                                    - 
com.hp.hpl.jena.tdb.transaction.TDBTransactionException: Transaction has 
already committed or aborted

interesting enough the 2nd message (produced around the same time as the 
previous error) is identical to what I found when running a different test to 
verify JENA-131. 
                
> QueryExecution.abort seems to corrupt TxTDB when interrupting transactional 
> queries
> -----------------------------------------------------------------------------------
>
>                 Key: JENA-143
>                 URL: https://issues.apache.org/jira/browse/JENA-143
>             Project: Jena
>          Issue Type: Bug
>          Components: TDB
>         Environment: tdb-0.9.0-20111010.121635
>            Reporter: Simon Helsen
>             Fix For: TDB 0.9.0
>
>
> The interaction between queryExecution.abort() and TxTDB transactions seems 
> to suffer from a problem. When I use it, it seems that the store corrupts 
> again. Note that when the QueryCancellationException is thrown, I actively 
> abort the DatasetGraphTxn object, but I am seeing 
> 14:59:20,580 [477961341@qtp-1709008349-8]  WARN 
> hpl.jena.sparql.engine.iterator.QueryIteratorCheck  - Open iterator: 
> QueryIterFilterExpr/37159
> and then shortly after:
> 15:00:34,691 [jazz.jfs.indexer.jfs_tests_default_consumer_name.triple] ERROR 
> com.ibm.team.jfs                                    - Originating Exception:
> com.hp.hpl.jena.tdb.base.file.FileException: 
> ObjectFile.read(8072)[12980][12980]: Impossibly large object : 1936010863 
> bytes
>       at 
> com.hp.hpl.jena.tdb.base.objectfile.ObjectFileStorage.read(ObjectFileStorage.java:294)
>       at 
> com.hp.hpl.jena.tdb.base.objectfile.ObjectFileStorage$ObjectIterator.next(ObjectFileStorage.java:409)
> This is the used coding pattern. The main thread just sets up the 
> transaction, so, something like this:
>       DatasetGraphTxn dsGraph = null;
>               try {
>                       dsGraph = 
> StoreConnection.make(this.location).begin(ReadWrite.READ);
>                       Dataset ds = dsGraph.toDataset();
>                       
>                       ...
>                       QueryExecution qe = null;
>                       ...
>                       try {
>                       results = qe.execSelect();
>                       ...
>                       } finally {
>                               if (qe != null) {
>                                       qe.close();
>                               }
>                       }
>               } catch (QueryCancelledException e) {
>                       if (dsGraph != null) {
>                               dsGraph.abort();
>                       }
>               }  finally {
>                       if (dsGraph != null) {
>                               dsGraph.close();
>                       }
>               }
> A parallel thread may decide that the given query needs to be cancelled, so 
> it has access to the QueryExecution and may decide to call
> this.queryExecution.abort(); 

--
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

        

Reply via email to