[
https://issues.apache.org/jira/browse/JENA-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13150764#comment-13150764
]
Simon Helsen commented on JENA-143:
-----------------------------------
In my attempt to adjust T_TransSystem, I was able to produce a problem by
aborting queries, but I am not 100% positive if this is the same problem as I
found in my own tests. Either way, I will attach a patch which should allow you
to reproduce a problem. The console in my last run was the following (where I
print CD to indicate an aborted describe query and CS to indicate an aborted
select query):
START (disk[direct], 1000 iterations)
000: . CD CS CD . CS CD CS CS CS .. CD ... CD CD . CS CS CS CS . CD .
CS .. CD . CD .. CS .. CD . CS .. CS .. CS CS CS . CD CD . CD CS CD . CS .
CS .. CS ... CS . CD CS . CD CS CD CD ... CS CD . CD CS ... CD .. CD . CD
CS . CS CS ..... CS . CD .. CS CS CD CD CS . CS .. CS .. CS CS CS CS
... CS CS ... CD CS ... CS CD CS . CS . CS CS . CS . CD CD ... CS CS .
CS ... CD . CD CS . CD . CS CS . CS .. CD ... CS .. CS .. CD .. CS CD . CS .
CS .. CD CS .. CS . CD CS .
CD CD CS CS CS 100: ... CD . CS CS .. CS CD .. CS CD ... CS CS .. CS
CS ..... CS . CD CS . CD CS . CS . CD CS .. CS . CS . CD CD CS .... CD CS
CD . CD CD . CD CS ..... CD .. CD . CS CS CS . CD . CS .. CS . CS CS . CS
. CD .... CS CS .. CS . CD ... CD CS . CD .... CS . CS CS . CD .. CD .....
CS CS CS CS . CS CD . CS .. CS . CS .. CD CS . CS . CS CS CS CS .. CS
CS CD .. CS .com.hp.hpl.jena.tdb.TDBException: Different ids for S: allocated:
expected [000000000000000E], got [0000000000000000]
at
com.hp.hpl.jena.tdb.transaction.NodeTableTrans.append(NodeTableTrans.java:178)
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:108)
at
com.hp.hpl.jena.tdb.transaction.Transaction.commit(Transaction.java:92)
at com.hp.hpl.jena.tdb.DatasetGraphTxn.commit(DatasetGraphTxn.java:38)
at
com.hp.hpl.jena.tdb.transaction.T_TransSystem$Writer.call(T_TransSystem.java:278)
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)
although the exact time when it happens differs between runs. Also, sometimes
when running the patched test, I seem to hit the deadlock in JENA-161. Because
I am having trouble to force a stack dump on my windows 64 bit machine, I am
not able to do much with the deadlock. I just cancel and restart the test in
those cases
> 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
