date:20181025

[jira] [Resolved] (JENA-1619) TransactionException for large query results

2018-10-25 Thread Andy Seaborne (JIRA)



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

Andy Seaborne resolved JENA-1619.
-
   Resolution: Fixed
 Assignee: Andy Seaborne
Fix Version/s: Jena 3.10.0

> TransactionException for large query results
> 
>
> Key: JENA-1619
> URL: https://issues.apache.org/jira/browse/JENA-1619
> Project: Apache Jena
>  Issue Type: Bug
>  Components: TDB2
>Affects Versions: Jena 3.9.0
> Environment: MacOS 10.14
> Java 1.8.0_161 (Oracle)
>Reporter: Damien Obrist
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.10.0
>
> Attachments: jena-transaction-exception-master.zip
>
>
> When querying a TDB2 dataset, I'm observing a suspicious 
> {{TransactionException}}, even though the query results have been copied so 
> they can be used outside of a transaction. The exception only seems to occur 
> when there are many results.
> h3. Reproduction steps
>  * Sample dataset containing 1'000'000 triples
>  * Query all triples:
> {code:java}
> SELECT * WHERE { ?s ?p ?o . }{code}
>  * Copy query results for use outside of transaction:
> {code:java}
> ResultSetFactory.copyResults(queryExecution.execSelect());{code}
>  * Get any variable of the first result
> All variables are {{null}} and the log shows the following exception:
> {noformat}
> org.apache.jena.dboe.transaction.txn.TransactionException: Not in a 
> transaction
>   at 
> org.apache.jena.dboe.transaction.txn.TransactionalComponentLifecycle.checkTxn(TransactionalComponentLifecycle.java:417)
>   at 
> org.apache.jena.dboe.trans.data.TransBinaryDataFile.read(TransBinaryDataFile.java:182)
>   at 
> org.apache.jena.tdb2.store.nodetable.TReadAppendFileTransport.read(TReadAppendFileTransport.java:71)
>   at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
>   at 
> org.apache.thrift.protocol.TCompactProtocol.readByte(TCompactProtocol.java:637)
>   at 
> org.apache.thrift.protocol.TCompactProtocol.readFieldBegin(TCompactProtocol.java:543)
>   at org.apache.thrift.TUnion$TUnionStandardScheme.read(TUnion.java:222)
>   at org.apache.thrift.TUnion$TUnionStandardScheme.read(TUnion.java:213)
>   at org.apache.thrift.TUnion.read(TUnion.java:138)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableTRDF.readNodeFromTable(NodeTableTRDF.java:80)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableNative._retrieveNodeByNodeId(NodeTableNative.java:103)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableNative.getNodeForNodeId(NodeTableNative.java:52)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableCache._retrieveNodeByNodeId(NodeTableCache.java:197)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableCache.getNodeForNodeId(NodeTableCache.java:108)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableWrapper.getNodeForNodeId(NodeTableWrapper.java:52)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableInline.getNodeForNodeId(NodeTableInline.java:66)
>   at org.apache.jena.tdb2.solver.BindingTDB.get1(BindingTDB.java:126)
>   at 
> org.apache.jena.sparql.engine.binding.BindingBase.get(BindingBase.java:104)
>   at org.apache.jena.sparql.core.ResultBinding._get(ResultBinding.java:57)
>   at 
> org.apache.jena.sparql.core.QuerySolutionBase.get(QuerySolutionBase.java:33)
>   at TransactionException.main(TransactionException.java:27)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:282)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I have created a minimal example available on 
> [GitHub|https://github.com/dobrist/jena-transaction-exception] and attached 
> to this issue.
> h3. Findings
>  * The exception doesn't occur for smaller query results
>  * This seems to be a regression as it works as expected with Jena 3.8.0
>  * Using {{git bisect}} I have identified the commit where this starts to 
> happen: 
> [9a60253|https://github.com/apache/jena/commit/9a60253c00aec6763adbb0253588fe4dc0b484d4]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1619) TransactionException for large query results

2018-10-25 Thread ASF GitHub Bot (JIRA)



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

ASF GitHub Bot commented on JENA-1619:
--

Github user asfgit closed the pull request at:

https://github.com/apache/jena/pull/482


> TransactionException for large query results
> 
>
> Key: JENA-1619
> URL: https://issues.apache.org/jira/browse/JENA-1619
> Project: Apache Jena
>  Issue Type: Bug
>  Components: TDB2
>Affects Versions: Jena 3.9.0
> Environment: MacOS 10.14
> Java 1.8.0_161 (Oracle)
>Reporter: Damien Obrist
>Priority: Major
> Attachments: jena-transaction-exception-master.zip
>
>
> When querying a TDB2 dataset, I'm observing a suspicious 
> {{TransactionException}}, even though the query results have been copied so 
> they can be used outside of a transaction. The exception only seems to occur 
> when there are many results.
> h3. Reproduction steps
>  * Sample dataset containing 1'000'000 triples
>  * Query all triples:
> {code:java}
> SELECT * WHERE { ?s ?p ?o . }{code}
>  * Copy query results for use outside of transaction:
> {code:java}
> ResultSetFactory.copyResults(queryExecution.execSelect());{code}
>  * Get any variable of the first result
> All variables are {{null}} and the log shows the following exception:
> {noformat}
> org.apache.jena.dboe.transaction.txn.TransactionException: Not in a 
> transaction
>   at 
> org.apache.jena.dboe.transaction.txn.TransactionalComponentLifecycle.checkTxn(TransactionalComponentLifecycle.java:417)
>   at 
> org.apache.jena.dboe.trans.data.TransBinaryDataFile.read(TransBinaryDataFile.java:182)
>   at 
> org.apache.jena.tdb2.store.nodetable.TReadAppendFileTransport.read(TReadAppendFileTransport.java:71)
>   at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
>   at 
> org.apache.thrift.protocol.TCompactProtocol.readByte(TCompactProtocol.java:637)
>   at 
> org.apache.thrift.protocol.TCompactProtocol.readFieldBegin(TCompactProtocol.java:543)
>   at org.apache.thrift.TUnion$TUnionStandardScheme.read(TUnion.java:222)
>   at org.apache.thrift.TUnion$TUnionStandardScheme.read(TUnion.java:213)
>   at org.apache.thrift.TUnion.read(TUnion.java:138)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableTRDF.readNodeFromTable(NodeTableTRDF.java:80)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableNative._retrieveNodeByNodeId(NodeTableNative.java:103)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableNative.getNodeForNodeId(NodeTableNative.java:52)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableCache._retrieveNodeByNodeId(NodeTableCache.java:197)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableCache.getNodeForNodeId(NodeTableCache.java:108)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableWrapper.getNodeForNodeId(NodeTableWrapper.java:52)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableInline.getNodeForNodeId(NodeTableInline.java:66)
>   at org.apache.jena.tdb2.solver.BindingTDB.get1(BindingTDB.java:126)
>   at 
> org.apache.jena.sparql.engine.binding.BindingBase.get(BindingBase.java:104)
>   at org.apache.jena.sparql.core.ResultBinding._get(ResultBinding.java:57)
>   at 
> org.apache.jena.sparql.core.QuerySolutionBase.get(QuerySolutionBase.java:33)
>   at TransactionException.main(TransactionException.java:27)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:282)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I have created a minimal example available on 
> [GitHub|https://github.com/dobrist/jena-transaction-exception] and attached 
> to this issue.
> h3. Findings
>  * The exception doesn't occur for smaller query results
>  * This seems to be a regression as it works as expected with Jena 3.8.0
>  * Using {{git bisect}} I have identified the commit where this starts to 
> happen: 
> [9a60253|https://github.com/apache/jena/commit/9a60253c00aec6763adbb0253588fe4dc0b484d4]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1619) TransactionException for large query results

2018-10-25 Thread ASF subversion and git services (JIRA)



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

ASF subversion and git services commented on JENA-1619:
---

Commit c3027d69ac87763113322876816fb6292ef6cd6a in jena's branch 
refs/heads/master from [~an...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=c3027d6 ]

JENA-1619: Merge commit 'refs/pull/482/head' of https://github.com/apache/jena

This closes #482.


> TransactionException for large query results
> 
>
> Key: JENA-1619
> URL: https://issues.apache.org/jira/browse/JENA-1619
> Project: Apache Jena
>  Issue Type: Bug
>  Components: TDB2
>Affects Versions: Jena 3.9.0
> Environment: MacOS 10.14
> Java 1.8.0_161 (Oracle)
>Reporter: Damien Obrist
>Priority: Major
> Attachments: jena-transaction-exception-master.zip
>
>
> When querying a TDB2 dataset, I'm observing a suspicious 
> {{TransactionException}}, even though the query results have been copied so 
> they can be used outside of a transaction. The exception only seems to occur 
> when there are many results.
> h3. Reproduction steps
>  * Sample dataset containing 1'000'000 triples
>  * Query all triples:
> {code:java}
> SELECT * WHERE { ?s ?p ?o . }{code}
>  * Copy query results for use outside of transaction:
> {code:java}
> ResultSetFactory.copyResults(queryExecution.execSelect());{code}
>  * Get any variable of the first result
> All variables are {{null}} and the log shows the following exception:
> {noformat}
> org.apache.jena.dboe.transaction.txn.TransactionException: Not in a 
> transaction
>   at 
> org.apache.jena.dboe.transaction.txn.TransactionalComponentLifecycle.checkTxn(TransactionalComponentLifecycle.java:417)
>   at 
> org.apache.jena.dboe.trans.data.TransBinaryDataFile.read(TransBinaryDataFile.java:182)
>   at 
> org.apache.jena.tdb2.store.nodetable.TReadAppendFileTransport.read(TReadAppendFileTransport.java:71)
>   at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
>   at 
> org.apache.thrift.protocol.TCompactProtocol.readByte(TCompactProtocol.java:637)
>   at 
> org.apache.thrift.protocol.TCompactProtocol.readFieldBegin(TCompactProtocol.java:543)
>   at org.apache.thrift.TUnion$TUnionStandardScheme.read(TUnion.java:222)
>   at org.apache.thrift.TUnion$TUnionStandardScheme.read(TUnion.java:213)
>   at org.apache.thrift.TUnion.read(TUnion.java:138)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableTRDF.readNodeFromTable(NodeTableTRDF.java:80)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableNative._retrieveNodeByNodeId(NodeTableNative.java:103)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableNative.getNodeForNodeId(NodeTableNative.java:52)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableCache._retrieveNodeByNodeId(NodeTableCache.java:197)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableCache.getNodeForNodeId(NodeTableCache.java:108)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableWrapper.getNodeForNodeId(NodeTableWrapper.java:52)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableInline.getNodeForNodeId(NodeTableInline.java:66)
>   at org.apache.jena.tdb2.solver.BindingTDB.get1(BindingTDB.java:126)
>   at 
> org.apache.jena.sparql.engine.binding.BindingBase.get(BindingBase.java:104)
>   at org.apache.jena.sparql.core.ResultBinding._get(ResultBinding.java:57)
>   at 
> org.apache.jena.sparql.core.QuerySolutionBase.get(QuerySolutionBase.java:33)
>   at TransactionException.main(TransactionException.java:27)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:282)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I have created a minimal example available on 
> [GitHub|https://github.com/dobrist/jena-transaction-exception] and attached 
> to this issue.
> h3. Findings
>  * The exception doesn't occur for smaller query results
>  * This seems to be a regression as it works as expected with Jena 3.8.0
>  * Using {{git bisect}} I have identified the commit where this starts to 
> happen: 
> [9a60253|https://github.com/apache/jena/commit/9a60253c00aec6763adbb0253588fe4dc0b484d4]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1619) TransactionException for large query results

2018-10-25 Thread ASF subversion and git services (JIRA)



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

ASF subversion and git services commented on JENA-1619:
---

Commit cd75e6c1597db5da1adf2eb3decd5bd59877b266 in jena's branch 
refs/heads/master from [~an...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=cd75e6c ]

JENA-1619: Completely detach a binding by doing a copy.

> TransactionException for large query results
> 
>
> Key: JENA-1619
> URL: https://issues.apache.org/jira/browse/JENA-1619
> Project: Apache Jena
>  Issue Type: Bug
>  Components: TDB2
>Affects Versions: Jena 3.9.0
> Environment: MacOS 10.14
> Java 1.8.0_161 (Oracle)
>Reporter: Damien Obrist
>Priority: Major
> Attachments: jena-transaction-exception-master.zip
>
>
> When querying a TDB2 dataset, I'm observing a suspicious 
> {{TransactionException}}, even though the query results have been copied so 
> they can be used outside of a transaction. The exception only seems to occur 
> when there are many results.
> h3. Reproduction steps
>  * Sample dataset containing 1'000'000 triples
>  * Query all triples:
> {code:java}
> SELECT * WHERE { ?s ?p ?o . }{code}
>  * Copy query results for use outside of transaction:
> {code:java}
> ResultSetFactory.copyResults(queryExecution.execSelect());{code}
>  * Get any variable of the first result
> All variables are {{null}} and the log shows the following exception:
> {noformat}
> org.apache.jena.dboe.transaction.txn.TransactionException: Not in a 
> transaction
>   at 
> org.apache.jena.dboe.transaction.txn.TransactionalComponentLifecycle.checkTxn(TransactionalComponentLifecycle.java:417)
>   at 
> org.apache.jena.dboe.trans.data.TransBinaryDataFile.read(TransBinaryDataFile.java:182)
>   at 
> org.apache.jena.tdb2.store.nodetable.TReadAppendFileTransport.read(TReadAppendFileTransport.java:71)
>   at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
>   at 
> org.apache.thrift.protocol.TCompactProtocol.readByte(TCompactProtocol.java:637)
>   at 
> org.apache.thrift.protocol.TCompactProtocol.readFieldBegin(TCompactProtocol.java:543)
>   at org.apache.thrift.TUnion$TUnionStandardScheme.read(TUnion.java:222)
>   at org.apache.thrift.TUnion$TUnionStandardScheme.read(TUnion.java:213)
>   at org.apache.thrift.TUnion.read(TUnion.java:138)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableTRDF.readNodeFromTable(NodeTableTRDF.java:80)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableNative._retrieveNodeByNodeId(NodeTableNative.java:103)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableNative.getNodeForNodeId(NodeTableNative.java:52)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableCache._retrieveNodeByNodeId(NodeTableCache.java:197)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableCache.getNodeForNodeId(NodeTableCache.java:108)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableWrapper.getNodeForNodeId(NodeTableWrapper.java:52)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableInline.getNodeForNodeId(NodeTableInline.java:66)
>   at org.apache.jena.tdb2.solver.BindingTDB.get1(BindingTDB.java:126)
>   at 
> org.apache.jena.sparql.engine.binding.BindingBase.get(BindingBase.java:104)
>   at org.apache.jena.sparql.core.ResultBinding._get(ResultBinding.java:57)
>   at 
> org.apache.jena.sparql.core.QuerySolutionBase.get(QuerySolutionBase.java:33)
>   at TransactionException.main(TransactionException.java:27)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:282)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I have created a minimal example available on 
> [GitHub|https://github.com/dobrist/jena-transaction-exception] and attached 
> to this issue.
> h3. Findings
>  * The exception doesn't occur for smaller query results
>  * This seems to be a regression as it works as expected with Jena 3.8.0
>  * Using {{git bisect}} I have identified the commit where this starts to 
> happen: 
> [9a60253|https://github.com/apache/jena/commit/9a60253c00aec6763adbb0253588fe4dc0b484d4]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] jena pull request #482: JENA-1619: Completely detach results by copying a bi...

2018-10-25 Thread asfgit

Github user asfgit closed the pull request at:

https://github.com/apache/jena/pull/482


---

[jira] [Commented] (JENA-1619) TransactionException for large query results

2018-10-25 Thread ASF subversion and git services (JIRA)



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

ASF subversion and git services commented on JENA-1619:
---

Commit c89ed1238bcee69918e7aeedaf52637c66ff315c in jena's branch 
refs/heads/master from [~an...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=c89ed12 ]

JENA-1619: Don't materialize bindings.

No need to materialize.
Bindings aren't safe outside a transaction anyway.

> TransactionException for large query results
> 
>
> Key: JENA-1619
> URL: https://issues.apache.org/jira/browse/JENA-1619
> Project: Apache Jena
>  Issue Type: Bug
>  Components: TDB2
>Affects Versions: Jena 3.9.0
> Environment: MacOS 10.14
> Java 1.8.0_161 (Oracle)
>Reporter: Damien Obrist
>Priority: Major
> Attachments: jena-transaction-exception-master.zip
>
>
> When querying a TDB2 dataset, I'm observing a suspicious 
> {{TransactionException}}, even though the query results have been copied so 
> they can be used outside of a transaction. The exception only seems to occur 
> when there are many results.
> h3. Reproduction steps
>  * Sample dataset containing 1'000'000 triples
>  * Query all triples:
> {code:java}
> SELECT * WHERE { ?s ?p ?o . }{code}
>  * Copy query results for use outside of transaction:
> {code:java}
> ResultSetFactory.copyResults(queryExecution.execSelect());{code}
>  * Get any variable of the first result
> All variables are {{null}} and the log shows the following exception:
> {noformat}
> org.apache.jena.dboe.transaction.txn.TransactionException: Not in a 
> transaction
>   at 
> org.apache.jena.dboe.transaction.txn.TransactionalComponentLifecycle.checkTxn(TransactionalComponentLifecycle.java:417)
>   at 
> org.apache.jena.dboe.trans.data.TransBinaryDataFile.read(TransBinaryDataFile.java:182)
>   at 
> org.apache.jena.tdb2.store.nodetable.TReadAppendFileTransport.read(TReadAppendFileTransport.java:71)
>   at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
>   at 
> org.apache.thrift.protocol.TCompactProtocol.readByte(TCompactProtocol.java:637)
>   at 
> org.apache.thrift.protocol.TCompactProtocol.readFieldBegin(TCompactProtocol.java:543)
>   at org.apache.thrift.TUnion$TUnionStandardScheme.read(TUnion.java:222)
>   at org.apache.thrift.TUnion$TUnionStandardScheme.read(TUnion.java:213)
>   at org.apache.thrift.TUnion.read(TUnion.java:138)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableTRDF.readNodeFromTable(NodeTableTRDF.java:80)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableNative._retrieveNodeByNodeId(NodeTableNative.java:103)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableNative.getNodeForNodeId(NodeTableNative.java:52)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableCache._retrieveNodeByNodeId(NodeTableCache.java:197)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableCache.getNodeForNodeId(NodeTableCache.java:108)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableWrapper.getNodeForNodeId(NodeTableWrapper.java:52)
>   at 
> org.apache.jena.tdb2.store.nodetable.NodeTableInline.getNodeForNodeId(NodeTableInline.java:66)
>   at org.apache.jena.tdb2.solver.BindingTDB.get1(BindingTDB.java:126)
>   at 
> org.apache.jena.sparql.engine.binding.BindingBase.get(BindingBase.java:104)
>   at org.apache.jena.sparql.core.ResultBinding._get(ResultBinding.java:57)
>   at 
> org.apache.jena.sparql.core.QuerySolutionBase.get(QuerySolutionBase.java:33)
>   at TransactionException.main(TransactionException.java:27)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:282)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I have created a minimal example available on 
> [GitHub|https://github.com/dobrist/jena-transaction-exception] and attached 
> to this issue.
> h3. Findings
>  * The exception doesn't occur for smaller query results
>  * This seems to be a regression as it works as expected with Jena 3.8.0
>  * Using {{git bisect}} I have identified the commit where this starts to 
> happen: 
> [9a60253|https://github.com/apache/jena/commit/9a60253c00aec6763adbb0253588fe4dc0b484d4]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Hash files of Apache Jena releases

2018-10-25 Thread Andy Seaborne


Temporary fixup done.

Andy

On 24/10/2018 21:54, Andy Seaborne wrote:
I can fix up the current dist/binaries as per (1), if that's OK.  As a 
fixup, this is not assuming it is the long term decision.



For 3.8.0, the format was the format of Linux sha512sum (not the other 
checksums) - that includes the file name and can be verify by sha512sum 
--verify, and end in a newline.


Maven generated chksums are just the checksum without giving the file 
name. This the style used in the maven artifacts and and the 
source-release sha512.


     Andy

On 24/10/2018 21:07, Andy Seaborne wrote:

The report is correct.

When we moved to SHA512 we had to additionally create them.

Then for 3.9.0, the Apache release profile did it for source-release. 
Doing it for source-release is the only required part in ASF release 
policy.


We can either
1: put back the addition step to add SHA512 the binaries
2: change the download page to reference the sha1's

I'm inclined to do (1) to keep the download page clean
(it needs the source-release being made more prominent IMO; this 
binaries downloads are nowadays rather less important than the maven 
channel).


Does anyone know of a standalone way to do "mvn 
dependency:copy-dependencies"? If there is such a thing, we can 
consider using the maven channel for non-maven usage.


 Andy

On 24/10/2018 16:38, Lucas Werkmeister wrote:

Hi!

I’m not sure if this email address is the best way to report the issue
(I found it when trying to “improve this page” using the link in the
upper right corner), but FYI: the Apache Jena Releases page [1] links to
SHA512 files for the downloads, but those files don’t actually exist;
instead, according to the automatically generated index [2], there are
SHA1 files. You might want to change your CGI script to link to those
instead.

Best regards,
Lucas Werkmeister

[1]: https://jena.apache.org/download/index.cgi
[2]: https://www.apache.org/dist/jena/binaries/

CMS diff: Jena-related projects and tools

2018-10-25 Thread Greg Albiston

Clone URL (Committers only):
https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://jena.apache.org/about_jena%2Fcontributions.mdtext

Greg Albiston

Index: trunk/content/about_jena/contributions.mdtext
===
--- trunk/content/about_jena/contributions.mdtext   (revision 1844793)
+++ trunk/content/about_jena/contributions.mdtext   (working copy)
@@ -31,4 +31,6 @@
 Persistence Annotations 4 RDF | Persistence Annotation for RDF (PAR) is a set 
of annotations and an entity manager that provides JPA like functionality on 
top of an RDF store while accounting for and exploiting the fundamental 
differences between graph storage and relational storage. PAR introduces three 
(3) annotations that map a RDF triple (subject, predicate, object) to a Plain 
Old Java Object (POJO) using Java's dynamic proxy capabilities. | Apache 2.0 | 
Claude Warren |  [PA4RDF at 
Sourceforge](https://sourceforge.net/projects/pa4rdf/)
 JenaSecurity | Security (Permissions) wrapper around Jena RDF implementation. 
| Apache 2.0 | Claude Warren | [JenaSecurity at 
GitHub](https://github.com/Claudenw/JenaSecurity)
 Semantic_Forms | Swiss army knife for data management and social networking. | 
open source | Jean-Marc Vanel | 
[Semantic_Forms](https://github.com/jmvanel/semantic_forms)
-JDBC 4 SPARQL | JDBC 4 SPARQL is a type 4 JDBC Driver that uses a SPARQL 
endpoint (or Jena Model) as the data store.  Presents graph data as relational 
data to tools that understand SQL and utilize JDBC| Apache 2.0 (Some components 
GNU LGPL V3.0) | Claude Warren | [jdbc4sparql at 
GitHub](https://github.com/Claudenw/jdbc4sparql)
\ No newline at end of file
+JDBC 4 SPARQL | JDBC 4 SPARQL is a type 4 JDBC Driver that uses a SPARQL 
endpoint (or Jena Model) as the data store.  Presents graph data as relational 
data to tools that understand SQL and utilize JDBC| Apache 2.0 (Some components 
GNU LGPL V3.0) | Claude Warren | [jdbc4sparql at 
GitHub](https://github.com/Claudenw/jdbc4sparql)
+GeoSPARQL Jena | Implementation of GeoSPARQL 1.0 standard using Apache Jena 
for SPARQL query or API. | Apache 2.0 | Greg Albiston and Haozhe Chen | 
[geosparql-jena at GitHub](https://github.com/galbiston/geosparql-jena)
+GeoSPARQL Fuseki | HTTP server application compliant with the GeoSPARQL 
standard using GeoSPARQL Jena library and Apache Jena Fuseki server | Apache 
2.0 | Greg Albiston | [geosparql-fuseki at 
GitHub](https://github.com/galbiston/geosparql-fuskei)
\ No newline at end of file

[jira] [Resolved] (JENA-1619) TransactionException for large query results

[jira] [Commented] (JENA-1619) TransactionException for large query results

[jira] [Commented] (JENA-1619) TransactionException for large query results

[jira] [Commented] (JENA-1619) TransactionException for large query results

[GitHub] jena pull request #482: JENA-1619: Completely detach results by copying a bi...

[jira] [Commented] (JENA-1619) TransactionException for large query results

Re: Hash files of Apache Jena releases

CMS diff: Jena-related projects and tools

8 matches

Site Navigation

Mail list logo

Footer information