[
https://issues.apache.org/jira/browse/JENA-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132720#comment-13132720
]
Simon Helsen commented on JENA-143:
-----------------------------------
Andy, I am sorry I am not able to produce a laboratory-clean setup, but as I
have explained many times before, TDB is deeply embedded in a complex
framework. We have about 1200 unit tests which do all sorts of stuff and they
run entirely green if I comment out QueryExecution.abort in the code which
manages cancellations. The only difference is of course that in that case, the
test suite which tests cancellation does not actually cancel the queries.
With regard to when the corruption shows up. It happens relatively soon after
the abort is initiated, but I have no clear information on when it happens. It
always starts with a few of the following warnings
WARN hpl.jena.sparql.engine.iterator.QueryIteratorCheck - Open iterator:
QueryIterFilterExpr/37159
and shortly after that the corruption spreads with the impossible large object
message and I have to stop the unit tests. I'll try to isolate the behavior
more, but having a unit tests which fires a few threads that query and one
other threads which aborts them in mid-execution may reproduce the problem.
Interesting enough, I don't think any write transaction is necessary to
reproduce, but I'll try to verify that
> 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
>
> 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
