Re: NullPointerExceptions in v3.6.0
Hi Andy,
It does seem weird. Just for completeness, I changed my first example to:
Model model = dataset.getDefaultModel();
model.add(new StatementImpl(
ModelFactory.createDefaultModel().createResource("http://example.org/thing
"),
FOAF.name,
ModelFactory.createDefaultModel().createLiteral("Chris")));
but (on Windows 10, at least) I still get the error.
Chris
On 5 March 2018 at 16:31, Andy Seaborne wrote:
>
>
> On 02/03/18 18:02, Chris Wood wrote:
>
>> Hi Andy,
>>
>> I've answered one question, but got another...
>>
>> Your comment "What is more, I can't line the stacktrace line numbers up
>> with the code. Jena 3.0.1 lines up better" made me sheepishly realise
>> that
>> my tdbquery path was pointing to an old version of Jena I had locally
>> (although this was actually v3.3.0). I changed tdbquery to use v3.6.0 and
>> it worked! But, it struck me that I'd worked on some other code recently
>> where I'd compiled with 3.6.0 but tested with tdbquery 3.3.0 and hadn't
>> seen errors - so I did some basic tests.
>>
>
> Even with a mix of versions, I could not reproduce the NPE. The DB format
> has not changed and ont at RDF 1.1 / Jena 3.0 was a reload needed.
>
> I've found that reading in a URL directly into a model doesn't result in
>> this error; i.e. using my previous workflow but using this version of
>> jena_test.java
>>
>>
>> import org.apache.jena.query.Dataset;
>> import org.apache.jena.query.ReadWrite;
>> import org.apache.jena.rdf.model.Model;
>> import org.apache.jena.rdf.model.ModelFactory;
>> import org.apache.jena.tdb.TDBFactory;
>>
>> public class jena_test {
>> public static void main(String args[])
>> {
>> Dataset dataset = TDBFactory.createDataset("my_dataset");
>> Model model = dataset.getDefaultModel();
>> dataset.begin(ReadWrite.WRITE);
>>
>> try{
>> model.add(ModelFactory.createDefaultModel().read("
>> https://www.w3.org/TR/REC-rdf-syntax/example14.nt";, "N-TRIPLE"));
>> dataset.commit();
>> } finally {
>> dataset.close();
>> }
>> }
>> }
>>
>
> In your first example theer are
>
> ModelFactory.createDefaultModel().createResource("person:1")
> ModelFactory.createDefaultModel().createResource("Chris")
>
> which are dubious URIs (the first is the "person:" URI schema, not a
> namespace of person, the second is a relative URI).
>
>
> https://www.w3.org/TR/REC-rdf-syntax/example14.nt
>
> is all good URIs.
>
> Andy
>
>
>>
>> with the same pom version but tdbquery v3.3.0
>>
>> C:\Users\chris\jena_test>tdbquery --version
>> Jena: VERSION: 3.3.0
>> Jena: BUILD_DATE: 2017-05-02T17:38:25+
>> ARQ:VERSION: 3.3.0
>> ARQ:BUILD_DATE: 2017-05-02T17:38:25+
>> RIOT: VERSION: 3.3.0
>> RIOT: BUILD_DATE: 2017-05-02T17:38:25+
>> TDB:VERSION: 3.3.0
>> TDB:BUILD_DATE: 2017-05-02T17:38:25+
>>
>>
>>
>> results in
>>
>> C:\Users\chris\jena_test >tdbquery --loc="my_dataset" "SELECT (count(*) as
>> ?t) where {?a ?b ?c . }"
>> -
>> | t |
>> =
>> | 2 |
>> -
>>
>> As expected.
>>
>> I recognise that using different versions of jena for compiling and for
>> tdbquery is almost certainly not supported (even if not implicitly), but
>> perhaps raising awareness from the troubles I've had this week might help
>> someone else!
>>
>> Cheers
>> Chris
>>
>>
>>
>>
>>
>> On 2 March 2018 at 13:38, Andy Seaborne wrote:
>>
>> Hi Chris,
>>>
>>> I am on Linux, with Apache Maven 3.5.2, java openjdk version "1.8.0_151".
>>>
>>> It works for me.
>>>
>>> What is more, I can't line the stacktrace line numbers up with the code.
>>> Jena 3.0.1 lines up better on
>>>
>>> JournalControl.recoverSegment(JournalControl.java:185)
>>>
>>> because that is a call to "replay"
>>>
>>>
>>> I ran the maven compiled version with
>>>
>>> java -cp target/classes:target/tdb_generator_resources/\* jena_test
>>>
>>> and then
>>>
>>> java -cp /home/afs/jlib/apache-jena-3.6.0/lib/\* tdb.tdbquery
>>> --loc=my_dataset 'SELECT (count(*) as ?t) where {?a ?b ?c . }'
>>>
>>> "tdbquery --version" ==>
>>>
>>> Jena: VERSION: 3.7.0-SNAPSHOT
>>> Jena: BUILD_DATE: 2018-02-27T22:54:52+
>>> ARQ:VERSION: 3.7.0-SNAPSHOT
>>> ARQ:BUILD_DATE: 2018-02-27T22:54:52+
>>> RIOT: VERSION: 3.7.0-SNAPSHOT
>>> RIOT: BUILD_DATE: 2018-02-27T22:54:52+
>>> TDB:VERSION: ${project.version}
>>> TDB:BUILD_DATE: ${build.time.xsd}
>>>
>>> (the TDB bit is old junk in 3.6.0 - ignore it)
>>>
>>> On 01/03/18 18:05, Chris Wood wrote:
>>>
>>> java -jar .\target\jena_test.jar
>>> The shade plugin wasn't configured to run, nor was it set to call the
>>> right main class.
>>>
>>> When I change the configuration, I also ran:
>>>
>>> java -jar target/jena_test.jar
>>>
>>> In all cases I got:
>>>
>>> -
>>> | t |
>>> =
>>> | 1 |
>>> -
>>>
>>> So it's still a mystery to me, I'm afraid.
>>>
>>> Andy
>>>
>>>
>>> org.apache.maven.plugins
>>> maven-shade-plugin
>>> 3.1.0
>>>
>>>
Re: NullPointerExceptions in v3.6.0
On 02/03/18 18:02, Chris Wood wrote:
Hi Andy,
I've answered one question, but got another...
Your comment "What is more, I can't line the stacktrace line numbers up
with the code. Jena 3.0.1 lines up better" made me sheepishly realise that
my tdbquery path was pointing to an old version of Jena I had locally
(although this was actually v3.3.0). I changed tdbquery to use v3.6.0 and
it worked! But, it struck me that I'd worked on some other code recently
where I'd compiled with 3.6.0 but tested with tdbquery 3.3.0 and hadn't
seen errors - so I did some basic tests.
Even with a mix of versions, I could not reproduce the NPE. The DB
format has not changed and ont at RDF 1.1 / Jena 3.0 was a reload needed.
I've found that reading in a URL directly into a model doesn't result in
this error; i.e. using my previous workflow but using this version of
jena_test.java
import org.apache.jena.query.Dataset;
import org.apache.jena.query.ReadWrite;
import org.apache.jena.rdf.model.Model;
import org.apache.jena.rdf.model.ModelFactory;
import org.apache.jena.tdb.TDBFactory;
public class jena_test {
public static void main(String args[])
{
Dataset dataset = TDBFactory.createDataset("my_dataset");
Model model = dataset.getDefaultModel();
dataset.begin(ReadWrite.WRITE);
try{
model.add(ModelFactory.createDefaultModel().read("
https://www.w3.org/TR/REC-rdf-syntax/example14.nt";, "N-TRIPLE"));
dataset.commit();
} finally {
dataset.close();
}
}
}
In your first example theer are
ModelFactory.createDefaultModel().createResource("person:1")
ModelFactory.createDefaultModel().createResource("Chris")
which are dubious URIs (the first is the "person:" URI schema, not a
namespace of person, the second is a relative URI).
https://www.w3.org/TR/REC-rdf-syntax/example14.nt
is all good URIs.
Andy
with the same pom version but tdbquery v3.3.0
C:\Users\chris\jena_test>tdbquery --version
Jena: VERSION: 3.3.0
Jena: BUILD_DATE: 2017-05-02T17:38:25+
ARQ:VERSION: 3.3.0
ARQ:BUILD_DATE: 2017-05-02T17:38:25+
RIOT: VERSION: 3.3.0
RIOT: BUILD_DATE: 2017-05-02T17:38:25+
TDB:VERSION: 3.3.0
TDB:BUILD_DATE: 2017-05-02T17:38:25+
results in
C:\Users\chris\jena_test >tdbquery --loc="my_dataset" "SELECT (count(*) as
?t) where {?a ?b ?c . }"
-
| t |
=
| 2 |
-
As expected.
I recognise that using different versions of jena for compiling and for
tdbquery is almost certainly not supported (even if not implicitly), but
perhaps raising awareness from the troubles I've had this week might help
someone else!
Cheers
Chris
On 2 March 2018 at 13:38, Andy Seaborne wrote:
Hi Chris,
I am on Linux, with Apache Maven 3.5.2, java openjdk version "1.8.0_151".
It works for me.
What is more, I can't line the stacktrace line numbers up with the code.
Jena 3.0.1 lines up better on
JournalControl.recoverSegment(JournalControl.java:185)
because that is a call to "replay"
I ran the maven compiled version with
java -cp target/classes:target/tdb_generator_resources/\* jena_test
and then
java -cp /home/afs/jlib/apache-jena-3.6.0/lib/\* tdb.tdbquery
--loc=my_dataset 'SELECT (count(*) as ?t) where {?a ?b ?c . }'
"tdbquery --version" ==>
Jena: VERSION: 3.7.0-SNAPSHOT
Jena: BUILD_DATE: 2018-02-27T22:54:52+
ARQ:VERSION: 3.7.0-SNAPSHOT
ARQ:BUILD_DATE: 2018-02-27T22:54:52+
RIOT: VERSION: 3.7.0-SNAPSHOT
RIOT: BUILD_DATE: 2018-02-27T22:54:52+
TDB:VERSION: ${project.version}
TDB:BUILD_DATE: ${build.time.xsd}
(the TDB bit is old junk in 3.6.0 - ignore it)
On 01/03/18 18:05, Chris Wood wrote:
java -jar .\target\jena_test.jar
The shade plugin wasn't configured to run, nor was it set to call the
right main class.
When I change the configuration, I also ran:
java -jar target/jena_test.jar
In all cases I got:
-
| t |
=
| 1 |
-
So it's still a mystery to me, I'm afraid.
Andy
org.apache.maven.plugins
maven-shade-plugin
3.1.0
package
shade
false
jena_test
Re: NullPointerExceptions in v3.6.0
Hi Andy,
I've answered one question, but got another...
Your comment "What is more, I can't line the stacktrace line numbers up
with the code. Jena 3.0.1 lines up better" made me sheepishly realise that
my tdbquery path was pointing to an old version of Jena I had locally
(although this was actually v3.3.0). I changed tdbquery to use v3.6.0 and
it worked! But, it struck me that I'd worked on some other code recently
where I'd compiled with 3.6.0 but tested with tdbquery 3.3.0 and hadn't
seen errors - so I did some basic tests.
I've found that reading in a URL directly into a model doesn't result in
this error; i.e. using my previous workflow but using this version of
jena_test.java
import org.apache.jena.query.Dataset;
import org.apache.jena.query.ReadWrite;
import org.apache.jena.rdf.model.Model;
import org.apache.jena.rdf.model.ModelFactory;
import org.apache.jena.tdb.TDBFactory;
public class jena_test {
public static void main(String args[])
{
Dataset dataset = TDBFactory.createDataset("my_dataset");
Model model = dataset.getDefaultModel();
dataset.begin(ReadWrite.WRITE);
try{
model.add(ModelFactory.createDefaultModel().read("
https://www.w3.org/TR/REC-rdf-syntax/example14.nt";, "N-TRIPLE"));
dataset.commit();
} finally {
dataset.close();
}
}
}
with the same pom version but tdbquery v3.3.0
C:\Users\chris\jena_test>tdbquery --version
Jena: VERSION: 3.3.0
Jena: BUILD_DATE: 2017-05-02T17:38:25+
ARQ:VERSION: 3.3.0
ARQ:BUILD_DATE: 2017-05-02T17:38:25+
RIOT: VERSION: 3.3.0
RIOT: BUILD_DATE: 2017-05-02T17:38:25+
TDB:VERSION: 3.3.0
TDB:BUILD_DATE: 2017-05-02T17:38:25+
results in
C:\Users\chris\jena_test >tdbquery --loc="my_dataset" "SELECT (count(*) as
?t) where {?a ?b ?c . }"
-
| t |
=
| 2 |
-
As expected.
I recognise that using different versions of jena for compiling and for
tdbquery is almost certainly not supported (even if not implicitly), but
perhaps raising awareness from the troubles I've had this week might help
someone else!
Cheers
Chris
On 2 March 2018 at 13:38, Andy Seaborne wrote:
> Hi Chris,
>
> I am on Linux, with Apache Maven 3.5.2, java openjdk version "1.8.0_151".
>
> It works for me.
>
> What is more, I can't line the stacktrace line numbers up with the code.
> Jena 3.0.1 lines up better on
>
> JournalControl.recoverSegment(JournalControl.java:185)
>
> because that is a call to "replay"
>
>
> I ran the maven compiled version with
>
> java -cp target/classes:target/tdb_generator_resources/\* jena_test
>
> and then
>
> java -cp /home/afs/jlib/apache-jena-3.6.0/lib/\* tdb.tdbquery
> --loc=my_dataset 'SELECT (count(*) as ?t) where {?a ?b ?c . }'
>
> "tdbquery --version" ==>
>
> Jena: VERSION: 3.7.0-SNAPSHOT
> Jena: BUILD_DATE: 2018-02-27T22:54:52+
> ARQ:VERSION: 3.7.0-SNAPSHOT
> ARQ:BUILD_DATE: 2018-02-27T22:54:52+
> RIOT: VERSION: 3.7.0-SNAPSHOT
> RIOT: BUILD_DATE: 2018-02-27T22:54:52+
> TDB:VERSION: ${project.version}
> TDB:BUILD_DATE: ${build.time.xsd}
>
> (the TDB bit is old junk in 3.6.0 - ignore it)
>
> On 01/03/18 18:05, Chris Wood wrote:
>
>> java -jar .\target\jena_test.jar
>>
>
> The shade plugin wasn't configured to run, nor was it set to call the
> right main class.
>
> When I change the configuration, I also ran:
>
> java -jar target/jena_test.jar
>
> In all cases I got:
>
> -
> | t |
> =
> | 1 |
> -
>
> So it's still a mystery to me, I'm afraid.
>
> Andy
>
>
> org.apache.maven.plugins
> maven-shade-plugin
> 3.1.0
>
>
> package
>
> shade
>
>
>
>
> false
>
> jena_test
>
>
>
Re: NullPointerExceptions in v3.6.0
Hi Chris,
I am on Linux, with Apache Maven 3.5.2, java openjdk version "1.8.0_151".
It works for me.
What is more, I can't line the stacktrace line numbers up with the code.
Jena 3.0.1 lines up better on
JournalControl.recoverSegment(JournalControl.java:185)
because that is a call to "replay"
I ran the maven compiled version with
java -cp target/classes:target/tdb_generator_resources/\* jena_test
and then
java -cp /home/afs/jlib/apache-jena-3.6.0/lib/\* tdb.tdbquery
--loc=my_dataset 'SELECT (count(*) as ?t) where {?a ?b ?c . }'
"tdbquery --version" ==>
Jena: VERSION: 3.7.0-SNAPSHOT
Jena: BUILD_DATE: 2018-02-27T22:54:52+
ARQ:VERSION: 3.7.0-SNAPSHOT
ARQ:BUILD_DATE: 2018-02-27T22:54:52+
RIOT: VERSION: 3.7.0-SNAPSHOT
RIOT: BUILD_DATE: 2018-02-27T22:54:52+
TDB:VERSION: ${project.version}
TDB:BUILD_DATE: ${build.time.xsd}
(the TDB bit is old junk in 3.6.0 - ignore it)
On 01/03/18 18:05, Chris Wood wrote:
java -jar .\target\jena_test.jar
The shade plugin wasn't configured to run, nor was it set to call the
right main class.
When I change the configuration, I also ran:
java -jar target/jena_test.jar
In all cases I got:
-
| t |
=
| 1 |
-
So it's still a mystery to me, I'm afraid.
Andy
org.apache.maven.plugins
maven-shade-plugin
3.1.0
package
shade
false
jena_test
Re: NullPointerExceptions in v3.6.0
Hi Andy (et al.),
I hope this is a minimal, reproducible example - and shows that I still get
the error after compilation with maven. If I run the same code as an
independent project in Eclipse (i.e. without maven integration) then it
works as expected and the final tdbquery command returns the result, rather
than an error.
Cheers
Chris
--
result of the `tree /F` command before compilation:
PS C:\Users\chris\jena_test> tree /F
Folder PATH listing for volume Windows
Volume serial number is 00BF 3C06:564C
C:.
│ .classpath
│ .project
│ mvnout.txt
│ pom.xml
│
├───.settings
│ org.eclipse.jdt.core.prefs
│ org.eclipse.m2e.core.prefs
│
└───src
└───main
└───java
jena_test.java
mvn version:
PS C:\Users\chris> mvn -version
Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T20:39:06+01:00)
Maven home: C:\tools\mvn\apache-maven-3.5.0\bin\..
Java version: 1.8.0_31, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_31\jre
Default locale: en_GB, platform encoding: Cp1252
OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"
---
jena_test.java:
import org.apache.jena.query.Dataset;
import org.apache.jena.query.ReadWrite;
import org.apache.jena.rdf.model.Model;
import org.apache.jena.rdf.model.ModelFactory;
import org.apache.jena.rdf.model.impl.StatementImpl;
import org.apache.jena.sparql.vocabulary.FOAF;
import org.apache.jena.tdb.TDBFactory;
public class jena_test {
public static void main(String[] args) {
Dataset dataset = TDBFactory.createDataset("my_dataset");
dataset.begin(ReadWrite.WRITE);
Model bodc_model = dataset.getDefaultModel();
try {
bodc_model.add(new StatementImpl(
ModelFactory.createDefaultModel().createResource("person:1"),
FOAF.name,
ModelFactory.createDefaultModel().createResource("Chris")));
dataset.commit();
} finally {
dataset.close();
}
}
}
---
pom.xml
http://maven.apache.org/POM/4.0.0"; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="
http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
test
jena_test
1.0.0
jar
org.apache.jena
apache-jena-libs
3.6.0
pom
${project.artifactId}
org.apache.maven.plugins
maven-compiler-plugin
2.1
1.8
1.8
org.apache.maven.plugins
maven-shade-plugin
3.1.0
false
org.apache.jena.fuseki.cmd.FusekiCmd
false
*:*
META-INF/*.SF
META-INF/*.DSA
META-INF/*.RSA
org.apache.maven.plugins
maven-dependency-plugin
2.5.1
copy-dependencies
package
copy-dependencies
${project.build.directory}/tdb_generator_resources/
org.apache.maven.plugins
maven-jar-plugin
3.0.2
true
tdb_generator_resources/
jena_test
---
result of the `tree /F` command after running `mvn compile package`:
PS C:\Users\chris\jena_test> tree /F
Folder PATH listing for volume Windows
Volume serial number is 00C0 3C06:564C
C:.
│ .classpath
│ .project
│ mvnout.txt
│ pom.xml
│
├───.settings
│ org.eclipse.jdt.core.prefs
│ org.eclipse.m2e.core.prefs
│
├───src
│ └───main
│ └───java
│ jena_test.java
│
└───target
│ jena_test.jar
│
├───classes
│ jena_test.class
│
├───maven-archiver
│ pom.properties
│
└───tdb_generator_resources
apache-jena-libs-3.6.0.pom
collection-0.7.jar
commons-cli-1.4.jar
commons-codec-1.9.jar
commons-csv-1.5.jar
commons-io-2.5.jar
commons-lang3-3.4.jar
httpclient-4.5.3.jar
httpclient-cache-4.5.3.jar
httpcore-4.4.6.jar
jackson-annotations-2.9.0.jar
jackson-core-2.9.0.jar
jackson-databind-2.9.0.jar
jcl-over-slf4j-1.7.25.jar
jena-arq-3.6.0.jar
jena-base-3.6.0.jar
jena-core-3.6.0.jar
Re: NullPointerExceptions in v3.6.0
Hi Andy,
Yeh, that was on my debugging list! I've seemingly tracked it down to a
maven problem. I'm working in eclipse: when I created a new project and
copied all the files across and ran it in eclipse, it worked; as soon as I
built and packed via maven, I got the error. I'll do some more digging...
Chris
On 28 February 2018 at 18:31, Andy Seaborne wrote:
> Chris,
>
> It looks like details matter - could you send a complete, minimal example
> (i.e. standalone and runnable)?
>
> Thanks
>
> Andy
>
> On 28/02/18 17:26, Chris Wood wrote:
>
>> Yeh, I thought I was doing that! I've taken that line of code out anyway
>> but it seems to make no difference...
>>
>> On 28 February 2018 at 16:55, Rob Vesse wrote:
>>
>> Notice that Andy specifically said in his response:
>>>
>>>call this very early (before any TDB related activity)
>>>
>>> Rob
>>>
>>> On 28/02/2018, 16:21, "Chris Wood" wrote:
>>>
>>> Hi Rob - sorry, that was an over-simplification of the psedocode; I
>>> do
>>> call
>>>
>>> dataset.begin(ReadWrite.WRITE);
>>>
>>> after initialising it.
>>>
>>> I had also wondered if setFileMode makes any difference - I was
>>> using
>>> it
>>> because of this Andy's comment here:
>>> http://users.jena.apache.narkive.com/zUPFzLcm/tdb-
>>> shutdown-does-not-release-the-files
>>>
>>> Chris
>>>
>>> On 28 February 2018 at 14:54, Rob Vesse
>>> wrote:
>>>
>>> > Two things look odd:
>>> >
>>> > - You never call dataset.begin() to start the transaction yet you
>>> later
>>> > try to commit() it
>>> > - Calling SystemTDB.setFileMode() after opening a dataset probably
>>> doesn't
>>> > have any effect on already open datasets though I could be wrong
>>> on
>>> this
>>> > point
>>> >
>>> > Rob
>>> >
>>> > On 28/02/2018, 13:08, "Chris Wood" wrote:
>>> >
>>> > Hi Andy,
>>> >
>>> > It's probably a bit more complicated than I originally
>>> suggested.
>>> > Inside my
>>> > try statement I do a bit of processing in a separate class (I
>>> create a
>>> > new
>>> > in-memory Dataset, and return the model from it, so I can add
>>> it
>>> to my
>>> > my
>>> > main dataset); but I also use this class to initialise the
>>> default
>>> > model. I
>>> > wonder if this is confusing the transaction...
>>> >
>>> > With a bit of pseudocode:
>>> >
>>> > Dataset dataset = TDBFactory.createDataset("path
>>> /to/tdb");
>>> > Model model = new Processing(dataset).;
>>> > SystemTDB.setFileMode(FileMode.direct);
>>> >
>>> > try {
>>> >Model m = model.dataStructure();
>>> >model.add(m);
>>> >dataset.commit();
>>> > } finally {
>>> >dataset.close();
>>> > }
>>> >
>>> > Processing.java:
>>> >
>>> > main:
>>> > public Processing(Dataset dataset) {
>>> > super(dataset.getDefaultModel().getGraph());
>>> > }
>>> >
>>> > dataStructure():
>>> > Dataset d1 = TDBFactory.createDataset();
>>> > Model m1 = d1.getDefaultModel();
>>> >
>>> > // add stuff to m1 from an independent datasource
>>> >
>>> > return m1;
>>> >
>>> >
>>> > On 28 February 2018 at 11:30, Andy Seaborne
>>> wrote:
>>> >
>>> > > Chris,
>>> > >
>>> > > Is the dataset TDB (from TDBFactory) or a dataset holding a
>>> model,
>>> > maybe
>>> > > with added inference, where the base graph is backed by TDB?
>>> > >
>>> > > It is better to put changes to the dataset inside a
>>> transaction.
>>> > Failing
>>> > > that, it should be sync'ed -- TDB.sync().
>>> > >
>>> > > Andy
>>> > >
>>> > > http://jena.staging.apache.org/documentation/txn/
>>> > >
>>> > > On 27/02/18 18:33, Chris Wood wrote:
>>> > >
>>> > >> I've got a small application that follows the standard
>>> recommended
>>> > >> pattern:
>>> > >>
>>> > >> // initialise dataset / model
>>> > >> ...
>>> > >> try {
>>> > >> // ... add statements
>>> > >> StmtIterator r = this.my_model.listStatements();
>>> > >> System.out.println(r.toList().size());
>>> > >> this.dataset.commit();
>>> > >> } catch (SQLException e) {
>>> > >> e.printStackTrace();
>>> > >> } finally {
>>> > >> this.dataset.close();
>>> > >> }
>>> > >>
>>> > >> I was running this with Jena 3.0.1, and all was fine. I've
>>> just
>>> > upgraded
>>> > >> to
>>> > >> 3.6.0. Whe
Re: NullPointerExceptions in v3.6.0
Chris,
It looks like details matter - could you send a complete, minimal
example (i.e. standalone and runnable)?
Thanks
Andy
On 28/02/18 17:26, Chris Wood wrote:
Yeh, I thought I was doing that! I've taken that line of code out anyway
but it seems to make no difference...
On 28 February 2018 at 16:55, Rob Vesse wrote:
Notice that Andy specifically said in his response:
call this very early (before any TDB related activity)
Rob
On 28/02/2018, 16:21, "Chris Wood" wrote:
Hi Rob - sorry, that was an over-simplification of the psedocode; I do
call
dataset.begin(ReadWrite.WRITE);
after initialising it.
I had also wondered if setFileMode makes any difference - I was using
it
because of this Andy's comment here:
http://users.jena.apache.narkive.com/zUPFzLcm/tdb-
shutdown-does-not-release-the-files
Chris
On 28 February 2018 at 14:54, Rob Vesse wrote:
> Two things look odd:
>
> - You never call dataset.begin() to start the transaction yet you
later
> try to commit() it
> - Calling SystemTDB.setFileMode() after opening a dataset probably
doesn't
> have any effect on already open datasets though I could be wrong on
this
> point
>
> Rob
>
> On 28/02/2018, 13:08, "Chris Wood" wrote:
>
> Hi Andy,
>
> It's probably a bit more complicated than I originally suggested.
> Inside my
> try statement I do a bit of processing in a separate class (I
create a
> new
> in-memory Dataset, and return the model from it, so I can add it
to my
> my
> main dataset); but I also use this class to initialise the
default
> model. I
> wonder if this is confusing the transaction...
>
> With a bit of pseudocode:
>
> Dataset dataset = TDBFactory.createDataset("path/to/tdb");
> Model model = new Processing(dataset).;
> SystemTDB.setFileMode(FileMode.direct);
>
> try {
>Model m = model.dataStructure();
>model.add(m);
>dataset.commit();
> } finally {
>dataset.close();
> }
>
> Processing.java:
>
> main:
> public Processing(Dataset dataset) {
> super(dataset.getDefaultModel().getGraph());
> }
>
> dataStructure():
> Dataset d1 = TDBFactory.createDataset();
> Model m1 = d1.getDefaultModel();
>
> // add stuff to m1 from an independent datasource
>
> return m1;
>
>
> On 28 February 2018 at 11:30, Andy Seaborne
wrote:
>
> > Chris,
> >
> > Is the dataset TDB (from TDBFactory) or a dataset holding a
model,
> maybe
> > with added inference, where the base graph is backed by TDB?
> >
> > It is better to put changes to the dataset inside a
transaction.
> Failing
> > that, it should be sync'ed -- TDB.sync().
> >
> > Andy
> >
> > http://jena.staging.apache.org/documentation/txn/
> >
> > On 27/02/18 18:33, Chris Wood wrote:
> >
> >> I've got a small application that follows the standard
recommended
> >> pattern:
> >>
> >> // initialise dataset / model
> >> ...
> >> try {
> >> // ... add statements
> >> StmtIterator r = this.my_model.listStatements();
> >> System.out.println(r.toList().size());
> >> this.dataset.commit();
> >> } catch (SQLException e) {
> >> e.printStackTrace();
> >> } finally {
> >> this.dataset.close();
> >> }
> >>
> >> I was running this with Jena 3.0.1, and all was fine. I've
just
> upgraded
> >> to
> >> 3.6.0. When I run the code and then check the tdb that is
generated
> with
> >> (on Windows):
> >>
> >> tdbquery --loc="database" "SELECT (count(*) as ?t)
where {?a
> ?b ?c
> >> . }"
> >>
> >> I get a NullPointerException:
> >>
> >> Exception
> >> java.lang.NullPointerException
> >> at
> >> org.apache.jena.tdb.transaction.JournalControl.replay(
> >> JournalControl.java:280)
> >> at
> >> org.apache.jena.tdb.transaction.JournalControl.recoverSegmen
> >> t(JournalControl.java:185)
> >> at
> >> org.apache.jena.tdb.transaction.JournalControl.recoverFromJo
> >> urnal(JournalControl.java:137)
> >> at
> >> org.apache.jena.tdb.StoreConnection.forceRecoverFromJournal(
> >> StoreConnection.j
Re: NullPointerExceptions in v3.6.0
Yeh, I thought I was doing that! I've taken that line of code out anyway
but it seems to make no difference...
On 28 February 2018 at 16:55, Rob Vesse wrote:
> Notice that Andy specifically said in his response:
>
> call this very early (before any TDB related activity)
>
> Rob
>
> On 28/02/2018, 16:21, "Chris Wood" wrote:
>
> Hi Rob - sorry, that was an over-simplification of the psedocode; I do
> call
>
> dataset.begin(ReadWrite.WRITE);
>
> after initialising it.
>
> I had also wondered if setFileMode makes any difference - I was using
> it
> because of this Andy's comment here:
> http://users.jena.apache.narkive.com/zUPFzLcm/tdb-
> shutdown-does-not-release-the-files
>
> Chris
>
> On 28 February 2018 at 14:54, Rob Vesse wrote:
>
> > Two things look odd:
> >
> > - You never call dataset.begin() to start the transaction yet you
> later
> > try to commit() it
> > - Calling SystemTDB.setFileMode() after opening a dataset probably
> doesn't
> > have any effect on already open datasets though I could be wrong on
> this
> > point
> >
> > Rob
> >
> > On 28/02/2018, 13:08, "Chris Wood" wrote:
> >
> > Hi Andy,
> >
> > It's probably a bit more complicated than I originally suggested.
> > Inside my
> > try statement I do a bit of processing in a separate class (I
> create a
> > new
> > in-memory Dataset, and return the model from it, so I can add it
> to my
> > my
> > main dataset); but I also use this class to initialise the
> default
> > model. I
> > wonder if this is confusing the transaction...
> >
> > With a bit of pseudocode:
> >
> > Dataset dataset = TDBFactory.createDataset("path/to/tdb");
> > Model model = new Processing(dataset).;
> > SystemTDB.setFileMode(FileMode.direct);
> >
> > try {
> >Model m = model.dataStructure();
> >model.add(m);
> >dataset.commit();
> > } finally {
> >dataset.close();
> > }
> >
> > Processing.java:
> >
> > main:
> > public Processing(Dataset dataset) {
> > super(dataset.getDefaultModel().getGraph());
> > }
> >
> > dataStructure():
> > Dataset d1 = TDBFactory.createDataset();
> > Model m1 = d1.getDefaultModel();
> >
> > // add stuff to m1 from an independent datasource
> >
> > return m1;
> >
> >
> > On 28 February 2018 at 11:30, Andy Seaborne
> wrote:
> >
> > > Chris,
> > >
> > > Is the dataset TDB (from TDBFactory) or a dataset holding a
> model,
> > maybe
> > > with added inference, where the base graph is backed by TDB?
> > >
> > > It is better to put changes to the dataset inside a
> transaction.
> > Failing
> > > that, it should be sync'ed -- TDB.sync().
> > >
> > > Andy
> > >
> > > http://jena.staging.apache.org/documentation/txn/
> > >
> > > On 27/02/18 18:33, Chris Wood wrote:
> > >
> > >> I've got a small application that follows the standard
> recommended
> > >> pattern:
> > >>
> > >> // initialise dataset / model
> > >> ...
> > >> try {
> > >> // ... add statements
> > >> StmtIterator r = this.my_model.listStatements();
> > >> System.out.println(r.toList().size());
> > >> this.dataset.commit();
> > >> } catch (SQLException e) {
> > >> e.printStackTrace();
> > >> } finally {
> > >> this.dataset.close();
> > >> }
> > >>
> > >> I was running this with Jena 3.0.1, and all was fine. I've
> just
> > upgraded
> > >> to
> > >> 3.6.0. When I run the code and then check the tdb that is
> generated
> > with
> > >> (on Windows):
> > >>
> > >> tdbquery --loc="database" "SELECT (count(*) as ?t)
> where {?a
> > ?b ?c
> > >> . }"
> > >>
> > >> I get a NullPointerException:
> > >>
> > >> Exception
> > >> java.lang.NullPointerException
> > >> at
> > >> org.apache.jena.tdb.transaction.JournalControl.replay(
> > >> JournalControl.java:280)
> > >> at
> > >> org.apache.jena.tdb.transaction.JournalControl.recoverSegmen
> > >> t(JournalControl.java:185)
> > >> at
> > >> org.apache.jena.tdb.transaction.JournalControl.recoverFromJo
> > >> urnal(JournalControl.java:137)
> > >> at
> > >> org.apache.jena.tdb.StoreConnection.forceRecoverFromJournal(
> > >> StoreConnection.java
Re: NullPointerExceptions in v3.6.0
Notice that Andy specifically said in his response:
call this very early (before any TDB related activity)
Rob
On 28/02/2018, 16:21, "Chris Wood" wrote:
Hi Rob - sorry, that was an over-simplification of the psedocode; I do call
dataset.begin(ReadWrite.WRITE);
after initialising it.
I had also wondered if setFileMode makes any difference - I was using it
because of this Andy's comment here:
http://users.jena.apache.narkive.com/zUPFzLcm/tdb-shutdown-does-not-release-the-files
Chris
On 28 February 2018 at 14:54, Rob Vesse wrote:
> Two things look odd:
>
> - You never call dataset.begin() to start the transaction yet you later
> try to commit() it
> - Calling SystemTDB.setFileMode() after opening a dataset probably doesn't
> have any effect on already open datasets though I could be wrong on this
> point
>
> Rob
>
> On 28/02/2018, 13:08, "Chris Wood" wrote:
>
> Hi Andy,
>
> It's probably a bit more complicated than I originally suggested.
> Inside my
> try statement I do a bit of processing in a separate class (I create a
> new
> in-memory Dataset, and return the model from it, so I can add it to my
> my
> main dataset); but I also use this class to initialise the default
> model. I
> wonder if this is confusing the transaction...
>
> With a bit of pseudocode:
>
> Dataset dataset = TDBFactory.createDataset("path/to/tdb");
> Model model = new Processing(dataset).;
> SystemTDB.setFileMode(FileMode.direct);
>
> try {
>Model m = model.dataStructure();
>model.add(m);
>dataset.commit();
> } finally {
>dataset.close();
> }
>
> Processing.java:
>
> main:
> public Processing(Dataset dataset) {
> super(dataset.getDefaultModel().getGraph());
> }
>
> dataStructure():
> Dataset d1 = TDBFactory.createDataset();
> Model m1 = d1.getDefaultModel();
>
> // add stuff to m1 from an independent datasource
>
> return m1;
>
>
> On 28 February 2018 at 11:30, Andy Seaborne wrote:
>
> > Chris,
> >
> > Is the dataset TDB (from TDBFactory) or a dataset holding a model,
> maybe
> > with added inference, where the base graph is backed by TDB?
> >
> > It is better to put changes to the dataset inside a transaction.
> Failing
> > that, it should be sync'ed -- TDB.sync().
> >
> > Andy
> >
> > http://jena.staging.apache.org/documentation/txn/
> >
> > On 27/02/18 18:33, Chris Wood wrote:
> >
> >> I've got a small application that follows the standard recommended
> >> pattern:
> >>
> >> // initialise dataset / model
> >> ...
> >> try {
> >> // ... add statements
> >> StmtIterator r = this.my_model.listStatements();
> >> System.out.println(r.toList().size());
> >> this.dataset.commit();
> >> } catch (SQLException e) {
> >> e.printStackTrace();
> >> } finally {
> >> this.dataset.close();
> >> }
> >>
> >> I was running this with Jena 3.0.1, and all was fine. I've just
> upgraded
> >> to
> >> 3.6.0. When I run the code and then check the tdb that is generated
> with
> >> (on Windows):
> >>
> >> tdbquery --loc="database" "SELECT (count(*) as ?t) where {?a
> ?b ?c
> >> . }"
> >>
> >> I get a NullPointerException:
> >>
> >> Exception
> >> java.lang.NullPointerException
> >> at
> >> org.apache.jena.tdb.transaction.JournalControl.replay(
> >> JournalControl.java:280)
> >> at
> >> org.apache.jena.tdb.transaction.JournalControl.recoverSegmen
> >> t(JournalControl.java:185)
> >> at
> >> org.apache.jena.tdb.transaction.JournalControl.recoverFromJo
> >> urnal(JournalControl.java:137)
> >> at
> >> org.apache.jena.tdb.StoreConnection.forceRecoverFromJournal(
> >> StoreConnection.java:150)
> >> at
> >> org.apache.jena.tdb.StoreConnection._makeAndCache(StoreConne
> >> ction.java:255)
> >> at
> >> org.apache.jena.tdb.StoreConnection.make(StoreConnection.java:214)
> >> at
> >> org.apache.jena.tdb.StoreConnection.make(StoreConnection.java:220)
> >> at
> >> org.apache.jena.tdb.transaction.DatasetGraphTransac
Re: NullPointerExceptions in v3.6.0
Hi Rob - sorry, that was an over-simplification of the psedocode; I do call
dataset.begin(ReadWrite.WRITE);
after initialising it.
I had also wondered if setFileMode makes any difference - I was using it
because of this Andy's comment here:
http://users.jena.apache.narkive.com/zUPFzLcm/tdb-shutdown-does-not-release-the-files
Chris
On 28 February 2018 at 14:54, Rob Vesse wrote:
> Two things look odd:
>
> - You never call dataset.begin() to start the transaction yet you later
> try to commit() it
> - Calling SystemTDB.setFileMode() after opening a dataset probably doesn't
> have any effect on already open datasets though I could be wrong on this
> point
>
> Rob
>
> On 28/02/2018, 13:08, "Chris Wood" wrote:
>
> Hi Andy,
>
> It's probably a bit more complicated than I originally suggested.
> Inside my
> try statement I do a bit of processing in a separate class (I create a
> new
> in-memory Dataset, and return the model from it, so I can add it to my
> my
> main dataset); but I also use this class to initialise the default
> model. I
> wonder if this is confusing the transaction...
>
> With a bit of pseudocode:
>
> Dataset dataset = TDBFactory.createDataset("path/to/tdb");
> Model model = new Processing(dataset).;
> SystemTDB.setFileMode(FileMode.direct);
>
> try {
>Model m = model.dataStructure();
>model.add(m);
>dataset.commit();
> } finally {
>dataset.close();
> }
>
> Processing.java:
>
> main:
> public Processing(Dataset dataset) {
> super(dataset.getDefaultModel().getGraph());
> }
>
> dataStructure():
> Dataset d1 = TDBFactory.createDataset();
> Model m1 = d1.getDefaultModel();
>
> // add stuff to m1 from an independent datasource
>
> return m1;
>
>
> On 28 February 2018 at 11:30, Andy Seaborne wrote:
>
> > Chris,
> >
> > Is the dataset TDB (from TDBFactory) or a dataset holding a model,
> maybe
> > with added inference, where the base graph is backed by TDB?
> >
> > It is better to put changes to the dataset inside a transaction.
> Failing
> > that, it should be sync'ed -- TDB.sync().
> >
> > Andy
> >
> > http://jena.staging.apache.org/documentation/txn/
> >
> > On 27/02/18 18:33, Chris Wood wrote:
> >
> >> I've got a small application that follows the standard recommended
> >> pattern:
> >>
> >> // initialise dataset / model
> >> ...
> >> try {
> >> // ... add statements
> >> StmtIterator r = this.my_model.listStatements();
> >> System.out.println(r.toList().size());
> >> this.dataset.commit();
> >> } catch (SQLException e) {
> >> e.printStackTrace();
> >> } finally {
> >> this.dataset.close();
> >> }
> >>
> >> I was running this with Jena 3.0.1, and all was fine. I've just
> upgraded
> >> to
> >> 3.6.0. When I run the code and then check the tdb that is generated
> with
> >> (on Windows):
> >>
> >> tdbquery --loc="database" "SELECT (count(*) as ?t) where {?a
> ?b ?c
> >> . }"
> >>
> >> I get a NullPointerException:
> >>
> >> Exception
> >> java.lang.NullPointerException
> >> at
> >> org.apache.jena.tdb.transaction.JournalControl.replay(
> >> JournalControl.java:280)
> >> at
> >> org.apache.jena.tdb.transaction.JournalControl.recoverSegmen
> >> t(JournalControl.java:185)
> >> at
> >> org.apache.jena.tdb.transaction.JournalControl.recoverFromJo
> >> urnal(JournalControl.java:137)
> >> at
> >> org.apache.jena.tdb.StoreConnection.forceRecoverFromJournal(
> >> StoreConnection.java:150)
> >> at
> >> org.apache.jena.tdb.StoreConnection._makeAndCache(StoreConne
> >> ction.java:255)
> >> at
> >> org.apache.jena.tdb.StoreConnection.make(StoreConnection.java:214)
> >> at
> >> org.apache.jena.tdb.StoreConnection.make(StoreConnection.java:220)
> >> at
> >> org.apache.jena.tdb.transaction.DatasetGraphTransaction.<
> >> init>(DatasetGraphTransaction.java:70)
> >> at org.apache.jena.tdb.sys.TDBMaker._create(TDBMaker.
> java:55)
> >> at
> >> org.apache.jena.tdb.sys.TDBMaker.createDatasetGraphTransacti
> >> on(TDBMaker.java:42)
> >> at
> >> org.apache.jena.tdb.TDBFactory._createDatasetGraph(TDBFactory.
> java:89)
> >> at
> >> org.apache.jena.tdb.TDBFactory.createDatasetGraph(
> TDBFactory.java:71)
> >> at org.apache.jena.tdb.TDBFactory.createDataset(
> TDBFactory.
> >> java:55)
> >> at tdb.cmdline.ModTDBDataset.createDataset(ModTDBDataset.
> java:
> >> 103)
> >> at arq.cmdline.ModDataset.getData
Re: NullPointerExceptions in v3.6.0
Two things look odd:
- You never call dataset.begin() to start the transaction yet you later try to
commit() it
- Calling SystemTDB.setFileMode() after opening a dataset probably doesn't have
any effect on already open datasets though I could be wrong on this point
Rob
On 28/02/2018, 13:08, "Chris Wood" wrote:
Hi Andy,
It's probably a bit more complicated than I originally suggested. Inside my
try statement I do a bit of processing in a separate class (I create a new
in-memory Dataset, and return the model from it, so I can add it to my my
main dataset); but I also use this class to initialise the default model. I
wonder if this is confusing the transaction...
With a bit of pseudocode:
Dataset dataset = TDBFactory.createDataset("path/to/tdb");
Model model = new Processing(dataset).;
SystemTDB.setFileMode(FileMode.direct);
try {
Model m = model.dataStructure();
model.add(m);
dataset.commit();
} finally {
dataset.close();
}
Processing.java:
main:
public Processing(Dataset dataset) {
super(dataset.getDefaultModel().getGraph());
}
dataStructure():
Dataset d1 = TDBFactory.createDataset();
Model m1 = d1.getDefaultModel();
// add stuff to m1 from an independent datasource
return m1;
On 28 February 2018 at 11:30, Andy Seaborne wrote:
> Chris,
>
> Is the dataset TDB (from TDBFactory) or a dataset holding a model, maybe
> with added inference, where the base graph is backed by TDB?
>
> It is better to put changes to the dataset inside a transaction. Failing
> that, it should be sync'ed -- TDB.sync().
>
> Andy
>
> http://jena.staging.apache.org/documentation/txn/
>
> On 27/02/18 18:33, Chris Wood wrote:
>
>> I've got a small application that follows the standard recommended
>> pattern:
>>
>> // initialise dataset / model
>> ...
>> try {
>> // ... add statements
>> StmtIterator r = this.my_model.listStatements();
>> System.out.println(r.toList().size());
>> this.dataset.commit();
>> } catch (SQLException e) {
>> e.printStackTrace();
>> } finally {
>> this.dataset.close();
>> }
>>
>> I was running this with Jena 3.0.1, and all was fine. I've just upgraded
>> to
>> 3.6.0. When I run the code and then check the tdb that is generated with
>> (on Windows):
>>
>> tdbquery --loc="database" "SELECT (count(*) as ?t) where {?a ?b ?c
>> . }"
>>
>> I get a NullPointerException:
>>
>> Exception
>> java.lang.NullPointerException
>> at
>> org.apache.jena.tdb.transaction.JournalControl.replay(
>> JournalControl.java:280)
>> at
>> org.apache.jena.tdb.transaction.JournalControl.recoverSegmen
>> t(JournalControl.java:185)
>> at
>> org.apache.jena.tdb.transaction.JournalControl.recoverFromJo
>> urnal(JournalControl.java:137)
>> at
>> org.apache.jena.tdb.StoreConnection.forceRecoverFromJournal(
>> StoreConnection.java:150)
>> at
>> org.apache.jena.tdb.StoreConnection._makeAndCache(StoreConne
>> ction.java:255)
>> at
>> org.apache.jena.tdb.StoreConnection.make(StoreConnection.java:214)
>> at
>> org.apache.jena.tdb.StoreConnection.make(StoreConnection.java:220)
>> at
>> org.apache.jena.tdb.transaction.DatasetGraphTransaction.<
>> init>(DatasetGraphTransaction.java:70)
>> at org.apache.jena.tdb.sys.TDBMaker._create(TDBMaker.java:55)
>> at
>> org.apache.jena.tdb.sys.TDBMaker.createDatasetGraphTransacti
>> on(TDBMaker.java:42)
>> at
>> org.apache.jena.tdb.TDBFactory._createDatasetGraph(TDBFactory.java:89)
>> at
>> org.apache.jena.tdb.TDBFactory.createDatasetGraph(TDBFactory.java:71)
>> at org.apache.jena.tdb.TDBFactory.createDataset(TDBFactory.
>> java:55)
>> at tdb.cmdline.ModTDBDataset.createDataset(ModTDBDataset.java:
>> 103)
>> at arq.cmdline.ModDataset.getDataset(ModDataset.java:36)
>> at arq.query.getDataset(query.java:176)
>> at arq.query.queryExec(query.java:213)
>> at arq.query.exec(query.java:153)
>> at jena.cmd.CmdMain.mainMethod(CmdMain.java:93)
>> at jena.cmd.CmdMain.mainRun(CmdMain.java:58)
>> at jena.cmd.CmdMain.mainRun(CmdMain.java:45)
>> at tdb.tdbquery.main(tdbquery.java:33)
>>
>> What seems really weird is that if I run the code *again* (without
>> deleting
>> the dataset directory) the triplestore is populated.
>>
>> - If I run the co
Re: NullPointerExceptions in v3.6.0
Hi Andy,
It's probably a bit more complicated than I originally suggested. Inside my
try statement I do a bit of processing in a separate class (I create a new
in-memory Dataset, and return the model from it, so I can add it to my my
main dataset); but I also use this class to initialise the default model. I
wonder if this is confusing the transaction...
With a bit of pseudocode:
Dataset dataset = TDBFactory.createDataset("path/to/tdb");
Model model = new Processing(dataset).;
SystemTDB.setFileMode(FileMode.direct);
try {
Model m = model.dataStructure();
model.add(m);
dataset.commit();
} finally {
dataset.close();
}
Processing.java:
main:
public Processing(Dataset dataset) {
super(dataset.getDefaultModel().getGraph());
}
dataStructure():
Dataset d1 = TDBFactory.createDataset();
Model m1 = d1.getDefaultModel();
// add stuff to m1 from an independent datasource
return m1;
On 28 February 2018 at 11:30, Andy Seaborne wrote:
> Chris,
>
> Is the dataset TDB (from TDBFactory) or a dataset holding a model, maybe
> with added inference, where the base graph is backed by TDB?
>
> It is better to put changes to the dataset inside a transaction. Failing
> that, it should be sync'ed -- TDB.sync().
>
> Andy
>
> http://jena.staging.apache.org/documentation/txn/
>
> On 27/02/18 18:33, Chris Wood wrote:
>
>> I've got a small application that follows the standard recommended
>> pattern:
>>
>> // initialise dataset / model
>> ...
>> try {
>> // ... add statements
>> StmtIterator r = this.my_model.listStatements();
>> System.out.println(r.toList().size());
>> this.dataset.commit();
>> } catch (SQLException e) {
>> e.printStackTrace();
>> } finally {
>> this.dataset.close();
>> }
>>
>> I was running this with Jena 3.0.1, and all was fine. I've just upgraded
>> to
>> 3.6.0. When I run the code and then check the tdb that is generated with
>> (on Windows):
>>
>> tdbquery --loc="database" "SELECT (count(*) as ?t) where {?a ?b ?c
>> . }"
>>
>> I get a NullPointerException:
>>
>> Exception
>> java.lang.NullPointerException
>> at
>> org.apache.jena.tdb.transaction.JournalControl.replay(
>> JournalControl.java:280)
>> at
>> org.apache.jena.tdb.transaction.JournalControl.recoverSegmen
>> t(JournalControl.java:185)
>> at
>> org.apache.jena.tdb.transaction.JournalControl.recoverFromJo
>> urnal(JournalControl.java:137)
>> at
>> org.apache.jena.tdb.StoreConnection.forceRecoverFromJournal(
>> StoreConnection.java:150)
>> at
>> org.apache.jena.tdb.StoreConnection._makeAndCache(StoreConne
>> ction.java:255)
>> at
>> org.apache.jena.tdb.StoreConnection.make(StoreConnection.java:214)
>> at
>> org.apache.jena.tdb.StoreConnection.make(StoreConnection.java:220)
>> at
>> org.apache.jena.tdb.transaction.DatasetGraphTransaction.<
>> init>(DatasetGraphTransaction.java:70)
>> at org.apache.jena.tdb.sys.TDBMaker._create(TDBMaker.java:55)
>> at
>> org.apache.jena.tdb.sys.TDBMaker.createDatasetGraphTransacti
>> on(TDBMaker.java:42)
>> at
>> org.apache.jena.tdb.TDBFactory._createDatasetGraph(TDBFactory.java:89)
>> at
>> org.apache.jena.tdb.TDBFactory.createDatasetGraph(TDBFactory.java:71)
>> at org.apache.jena.tdb.TDBFactory.createDataset(TDBFactory.
>> java:55)
>> at tdb.cmdline.ModTDBDataset.createDataset(ModTDBDataset.java:
>> 103)
>> at arq.cmdline.ModDataset.getDataset(ModDataset.java:36)
>> at arq.query.getDataset(query.java:176)
>> at arq.query.queryExec(query.java:213)
>> at arq.query.exec(query.java:153)
>> at jena.cmd.CmdMain.mainMethod(CmdMain.java:93)
>> at jena.cmd.CmdMain.mainRun(CmdMain.java:58)
>> at jena.cmd.CmdMain.mainRun(CmdMain.java:45)
>> at tdb.tdbquery.main(tdbquery.java:33)
>>
>> What seems really weird is that if I run the code *again* (without
>> deleting
>> the dataset directory) the triplestore is populated.
>>
>> - If I run the code ensuring I use v3.0.1, this doesn't happen, and the
>> tdbquery command works on the first attempt.
>> - The print statement showing the number of statements in the dataset
>> shows the correct number in all cases.
>>
>> What has changed between 3.0.1 and 3.6.0 to cause this (and any hints on
>> what I need to do to resolve it would be greatly appreciated!)
>>
>> Thanks
>> Chris
>>
>>
Re: NullPointerExceptions in v3.6.0
Chris,
Is the dataset TDB (from TDBFactory) or a dataset holding a model, maybe
with added inference, where the base graph is backed by TDB?
It is better to put changes to the dataset inside a transaction. Failing
that, it should be sync'ed -- TDB.sync().
Andy
http://jena.staging.apache.org/documentation/txn/
On 27/02/18 18:33, Chris Wood wrote:
I've got a small application that follows the standard recommended pattern:
// initialise dataset / model
...
try {
// ... add statements
StmtIterator r = this.my_model.listStatements();
System.out.println(r.toList().size());
this.dataset.commit();
} catch (SQLException e) {
e.printStackTrace();
} finally {
this.dataset.close();
}
I was running this with Jena 3.0.1, and all was fine. I've just upgraded to
3.6.0. When I run the code and then check the tdb that is generated with
(on Windows):
tdbquery --loc="database" "SELECT (count(*) as ?t) where {?a ?b ?c . }"
I get a NullPointerException:
Exception
java.lang.NullPointerException
at
org.apache.jena.tdb.transaction.JournalControl.replay(JournalControl.java:280)
at
org.apache.jena.tdb.transaction.JournalControl.recoverSegment(JournalControl.java:185)
at
org.apache.jena.tdb.transaction.JournalControl.recoverFromJournal(JournalControl.java:137)
at
org.apache.jena.tdb.StoreConnection.forceRecoverFromJournal(StoreConnection.java:150)
at
org.apache.jena.tdb.StoreConnection._makeAndCache(StoreConnection.java:255)
at
org.apache.jena.tdb.StoreConnection.make(StoreConnection.java:214)
at
org.apache.jena.tdb.StoreConnection.make(StoreConnection.java:220)
at
org.apache.jena.tdb.transaction.DatasetGraphTransaction.(DatasetGraphTransaction.java:70)
at org.apache.jena.tdb.sys.TDBMaker._create(TDBMaker.java:55)
at
org.apache.jena.tdb.sys.TDBMaker.createDatasetGraphTransaction(TDBMaker.java:42)
at
org.apache.jena.tdb.TDBFactory._createDatasetGraph(TDBFactory.java:89)
at
org.apache.jena.tdb.TDBFactory.createDatasetGraph(TDBFactory.java:71)
at org.apache.jena.tdb.TDBFactory.createDataset(TDBFactory.java:55)
at tdb.cmdline.ModTDBDataset.createDataset(ModTDBDataset.java:103)
at arq.cmdline.ModDataset.getDataset(ModDataset.java:36)
at arq.query.getDataset(query.java:176)
at arq.query.queryExec(query.java:213)
at arq.query.exec(query.java:153)
at jena.cmd.CmdMain.mainMethod(CmdMain.java:93)
at jena.cmd.CmdMain.mainRun(CmdMain.java:58)
at jena.cmd.CmdMain.mainRun(CmdMain.java:45)
at tdb.tdbquery.main(tdbquery.java:33)
What seems really weird is that if I run the code *again* (without deleting
the dataset directory) the triplestore is populated.
- If I run the code ensuring I use v3.0.1, this doesn't happen, and the
tdbquery command works on the first attempt.
- The print statement showing the number of statements in the dataset
shows the correct number in all cases.
What has changed between 3.0.1 and 3.6.0 to cause this (and any hints on
what I need to do to resolve it would be greatly appreciated!)
Thanks
Chris
