You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@apache.org> on 2012/06/01 15:26:02 UTC
Release 2.7.1
I've uploaded the three zip files that the build produces (not done as a
maven release, just built against trunk) for inspection.
http://people.apache.org/~andy/Jena-2.7.1/
apache-jena-2.7.1-SNAPSHOT.zip
jena-2.7.1-SNAPSHOT-source-release.zip
jena-fuseki-0.2.2-SNAPSHOT-distribution.zip
Andy
Re: Release 2.7.1
Posted by Simon Helsen <sh...@ca.ibm.com>.
I created
https://issues.apache.org/jira/browse/JENA-252
to track this problem
Simon
From:
Simon Helsen/Toronto/IBM@IBMCA
To:
dev@jena.apache.org
Cc:
dev@jena.apache.org
Date:
06/08/2012 02:55 PM
Subject:
Re: Release 2.7.1
hi again,
k, so, it is tricky to distill a test case out of our framework because
this one is based on multiple threads, but I am debugging it myself
instead.
So, I put the breakpoint in DatasetControlMRSW.policyError where the cme
is thrown. When I do that and rerun the test suite, I get into a scenario
where 4 threads hang on the breakpoint. 3 of these are 'read' threads and
1 is a 'write' thread. Now, the writeCounter says it has 4 (and the
readCounter is 0), which is why the cme is thrown. So, the question is why
the writeCounter says 4.
In order to find that out, I set a different breakpoint at startUpdate in
DatasetControlMRSW. I notice that it came from a query, i.e. a READ
transaction. The violating code is this:
@Override
protected void _begin(ReadWrite readWrite)
{
synchronized(lock)
{
if ( ! haveUsedInTransaction )
getBaseDatasetGraph().sync() ;
haveUsedInTransaction = true ;
DatasetGraphTxn dsgTxn = sConn.begin(readWrite) ;
txn.set(dsgTxn) ;
inTransaction.set(true) ;
}
}
The bit
if ( ! haveUsedInTransaction )
getBaseDatasetGraph().sync() ;
is the problem. It calls prefixes.sync() which calls nodeTupleTable.sync()
which calls startWrite() ;
any ideas how to fix this?
Simon
From:
Simon Helsen/Toronto/IBM@IBMCA
To:
dev@jena.apache.org
Cc:
dev@jena.apache.org
Date:
06/08/2012 02:09 PM
Subject:
Re: Release 2.7.1
btw, that is the first exception I see. After that, I see different other
exceptions, but I suspect they are a consequence of this one
e.g.
Caused by: java.lang.NullPointerException
at com.hp.hpl.jena.tdb.transaction.DatasetGraphTransaction._end(
DatasetGraphTransaction.java:168)
at com.hp.hpl.jena.tdb.migrate.DatasetGraphTrackActive.end(
DatasetGraphTrackActive.java:76)
at com.hp.hpl.jena.sparql.core.DatasetImpl.end(
DatasetImpl.java:159)
at
com.ibm.team.jfs.rdf.internal.jena.tdb.JenaTxTdbProvider.storeOperation(
JenaTxTdbProvider.java:196)
at com.ibm.team.jfs.rdf.internal.jena.tdb.JenaTxTdbProvider.query(
JenaTxTdbProvider.java:1573)
... 39 more
From:
Simon Helsen/Toronto/IBM@IBMCA
To:
dev@jena.apache.org
Cc:
"dev@jena.apache.org" <de...@jena.apache.org>
Date:
06/08/2012 02:00 PM
Subject:
Re: Release 2.7.1
Andy,
since your latest fix, I am running into another serious error I have not
seen before. It is possible that the problem is on our end - I will
investigate, but since I didn't touch any code, I am rather worried the
issue is related to your fix for 250.
I would rather have you hold off 2.7.1 and make sure things are ok.
I know you need test cases etc, but let me already provide a stack trace
to show the seriousness of the problem
Simon
13:01:36,504 [273813586@qtp-2076933067-43] ERROR com.ibm.team.jfs -
Originating Exception:
java.util.ConcurrentModificationException: Reader = 0, Writer = 2
at com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.policyError(
DatasetControlMRSW.java:157)
at com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.policyError(
DatasetControlMRSW.java:152)
at com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.checkConcurrency(
DatasetControlMRSW.java:81)
at com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.startUpdate(
DatasetControlMRSW.java:60)
at
com.hp.hpl.jena.tdb.nodetable.NodeTupleTableConcrete.startWrite(
NodeTupleTableConcrete.java:64)
at com.hp.hpl.jena.tdb.nodetable.NodeTupleTableConcrete.sync(
NodeTupleTableConcrete.java:255)
at com.hp.hpl.jena.tdb.store.DatasetPrefixesTDB.sync(
DatasetPrefixesTDB.java:235)
at com.hp.hpl.jena.tdb.store.DatasetGraphTDB.sync(
DatasetGraphTDB.java:283)
at com.hp.hpl.jena.tdb.transaction.DatasetGraphTransaction._begin(
DatasetGraphTransaction.java:143)
at com.hp.hpl.jena.tdb.migrate.DatasetGraphTrackActive.begin(
DatasetGraphTrackActive.java:52)
at com.hp.hpl.jena.sparql.core.DatasetImpl.begin(
DatasetImpl.java:126)
at
com.ibm.team.jfs.rdf.internal.jena.tdb.JenaTxTdbProvider.storeOperation(
JenaTxTdbProvider.java:183)
at com.ibm.team.jfs.rdf.internal.jena.tdb.JenaTxTdbProvider.query(
JenaTxTdbProvider.java:1573)
at
com.ibm.team.jfs.rdf.internal.jena.JenaQueryService.performQuery(
JenaQueryService.java:511)
at
com.ibm.team.jfs.rdf.internal.jena.JenaQueryService.perform_GET(
JenaQueryService.java:225)
at com.ibm.team.repository.service.TeamRawService.service(
TeamRawService.java:82)
at sun.reflect.GeneratedMethodAccessor221.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at
org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord.invoke(
ExportProxyServiceRecord.java:361)
at
org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord.access$0(
ExportProxyServiceRecord.java:347)
at
org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord$ExportedServiceInvocationHandler.invoke(
ExportProxyServiceRecord.java:56)
at $Proxy21075.service(Unknown Source)
at
com.ibm.team.repository.servlet.AbstractTeamServerServlet.doRestService(
AbstractTeamServerServlet.java:872)
at
com.ibm.team.repository.servlet.AbstractTeamServerServlet.handleRequest2(
AbstractTeamServerServlet.java:2054)
at
com.ibm.team.repository.servlet.AbstractTeamServerServlet.handleRequest(
AbstractTeamServerServlet.java:1878)
at
com.ibm.team.repository.servlet.AbstractTeamServerServlet.access$0(
AbstractTeamServerServlet.java:1863)
at
com.ibm.team.repository.servlet.AbstractTeamServerServlet$1.service(
AbstractTeamServerServlet.java:208)
at
com.ibm.team.repository.service.internal.oauth.OAuthServiceProvider$3.run(
OAuthServiceProvider.java:763)
at
com.ibm.team.repository.servlet.AbstractTeamServerServlet.service(
AbstractTeamServerServlet.java:1682)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.eclipse.equinox.http.registry.internal.ServletManager$ServletWrapper.service(
ServletManager.java:180)
at
org.eclipse.equinox.http.servlet.internal.ServletRegistration.service(
ServletRegistration.java:61)
at
org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(
ProxyServlet.java:126)
at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(
ProxyServlet.java:76)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(
ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler.handle(
ServletHandler.java:390)
at org.mortbay.jetty.security.SecurityHandler.handle(
SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(
SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(
ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(
WebAppContext.java:418)
at org.mortbay.jetty.handler.HandlerWrapper.handle(
HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(
HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(
HttpConnection.java:924)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212
)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404
)
at org.mortbay.jetty.bio.SocketConnector$Connection.run(
SocketConnector.java:228)
at
org.mortbay.jetty.security.SslSocketConnector$SslConnection.run(
SslSocketConnector.java:680)
From:
Rob Vesse <rv...@yarcdata.com>
To:
"dev@jena.apache.org" <de...@jena.apache.org>
Date:
06/08/2012 01:04 PM
Subject:
Re: Release 2.7.1
Thanks for pushing forward on this Andy, I wish I had more time to do
stuff on Jena at the moment as there's bits and pieces that I'd like to
work on (e.g. Streaming parsing on SPARQL JSON, war-ifying Fuseki etc)
that I don't have the cycles for right now
Thanks for all the work
Rob
On 6/8/12 9:54 AM, "Andy Seaborne" <an...@apache.org> wrote:
>With the (hopeful) resolution of JENA-250, I have rebuilt the
>pre-release binaries:
>
>http://people.apache.org/~andy/Jena-2.7.1/
>
>apache-jena-2.7.1-SNAPSHOT.zip
>jena-2.7.1-SNAPSHOT-source-release.zip
>jena-fuseki-0.2.2-SNAPSHOT-distribution.zip
>
>At this point, I have one oddity I noticed in TDB I want to investigate
>- this is probably nothing more than me not remembering how the
>transactional node table actually works.
>
>Other than that I will do the formal build and call the vote. Even if
>something in TDB is not optimal, I am very unlikely to change anything
>at this stage. It is better to go with deployment-tested code than with
>an "improvement" then test out changes and issue an incremental release
>quite soon.
>
> Andy
slower query?
Posted by Simon Helsen <sh...@ca.ibm.com>.
on another note.
while rolling out prototype builds with 2.7.1, one of our clients came
back and complained about a query being excessively slow compared to
before (like 10 times or more). The query was strangely written so I
helped them change it to something more "natural" which made the query
more acceptable in speed. It was still a little bit slower, but since that
was in Tx, we can probably live with that. I need to get back to them to
how much the comparison was. As I have mentioned before, we were still on
jena 2.6.3 and associated libraries, but it puzzles me that Jena 2.7.1
does a worse job on this (admittedly badly written) query. Anyone has an
idea why this could be?
This is the originally written query (fast on 2.6.3, extremely slow on
2.7.1)
PREFIX jfs: <http://jazz.net/xmlns/foundation/1.0/>
CONSTRUCT { ?s ?p ?o . } WHERE {
GRAPH ?g {
?s ?p ?o .
}
?doc jfs:resourceLocation ?g .
FILTER ((?g = <documentUriGoesHere>) && (?s != ?doc))
}
I made our client rewrite it to the following (fast on 2.6.3, fast on
2.7.1, if a bit slower than on 2.6.3)
PREFIX jfs: <http://jazz.net/xmlns/foundation/1.0/>
CONSTRUCT { ?s ?p ?o . } WHERE {
GRAPH <documentUriGoesHere> {
?s ?p ?o .
}
?doc jfs:resourceLocation <documentUriGoesHere> .
FILTER (?s != ?doc)
}
So, the question is why Jena 2.6.3 was able to still do a good job with
the former. I must admit that if I had seen the former and didn't know
2.6.3 was able to run this fast, I would always have thought that it would
be slow because unless ARQ inlines the constraint on ?g, the only solution
path I see is to essentially fetch the entire triple store and match the
filter as you go.
thanks
Simon
Re: Release 2.7.1
Posted by Simon Helsen <sh...@ca.ibm.com>.
JENA-252. I will update JENA-250 shortly
From:
Andy Seaborne <an...@apache.org>
To:
Simon Helsen/Toronto/IBM@IBMCA
Cc:
dev@jena.apache.org
Date:
06/09/2012 07:58 AM
Subject:
Re: Release 2.7.1
On 08/06/12 23:05, Simon Helsen wrote:
> that seems to work.
Is that confirmation JENA-250 is working OK now the concurrency clash
(JENA-252) is addressed?
Andy
Re: Release 2.7.1
Posted by Andy Seaborne <an...@apache.org>.
On 08/06/12 23:05, Simon Helsen wrote:
> that seems to work.
Is that confirmation JENA-250 is working OK now the concurrency clash
(JENA-252) is addressed?
Andy
Re: Release 2.7.1
Posted by Andy Seaborne <an...@apache.org>.
On 08/06/12 23:05, Simon Helsen wrote:
> that seems to work. So the lock attribute is useless now. I am not
> entirely sure why this fixes things since I cannot see anyone else
> synchronizing on sConn, but I assume that happens somewhere outside.
Each StoreConnection has a TransactionManager, and
TransactionManager.begin$ is synchronized so implicitly sConn is locked.
> I added a comment to https://issues.apache.org/jira/browse/JENA-252
More details there.
(if JIRA is running; there is a maintenance notice for major reorg of
the hardware/VMs today)
Andy
>
>
> From: Simon Helsen/Toronto/IBM@IBMCA
> To: dev@jena.apache.org
> Cc: Andy Seaborne <an...@gmail.com>, dev@jena.apache.org
> Date: 06/08/2012 05:01 PM
> Subject: Re: Release 2.7.1
>
>
> ------------------------------------------------------------------------
>
>
>
> I'll try the proposed fix.
>
> If you can tell me what you're looking for, I can debug this further. What
> exactly do you mean by "It's hard to tell without how the
> DatasetGraphTransaction's get made"?
>
> As for the style, I followed the documentation on multiple threads, so I
> create a dataset for each transaction and close it. A transaction is
> unique per thread, i.e. not shared as recommended. You saw the model
> already in the test I provide for 250, so we have something like this
>
> private <E> E storeOperation(String query, QueryActivity<E>
> queryActivity) {
> Dataset dataset = TDBFactory.createDataset(this.location);
> QueryExecution qe = null;
> try {
> dataset.begin(ReadWrite.READ) ;
> qe = QueryExecutionFactory.create(query, dataset);
> E e = queryActivity.run(qe);
> dataset.commit();
> return e;
> } catch (Throwable e) {
> dataset.abort();
> throw new RuntimeException(e);
> } finally {
> try {
> if (qe != null) {
> qe.close();
> }
> } finally {
> dataset.end();
> }
> }
> }
>
> for a query - and FYI, we do not allow update queries. There are some
> other variations of this for type of reads, but in my test case it looks
> like this is the one being used by the read transactions. Then we use this
> one for writes:
>
> private <E> E storeOperation(String graphName, ModelWriteActivity<E>
> modelWriteActivity) {
> Dataset dataset = TDBFactory.createDataset(this.location);
> try {
> dataset.begin(ReadWrite.WRITE);
> Model m = dataset.getNamedModel(graphName);
> E e = modelWriteActivity.run(m);
> dataset.commit();
> return e;
> } catch (Throwable e) {
> dataset.abort();
> throw new RuntimeException(e);
> } finally {
> dataset.end();
> }
> }
>
> and we have one for multiple models per transaction. Each of these are
> executed within their own thread. The dataset is (obviously) never shared
>
> Simon
>
>
>
>
>
>
> From:
> Andy Seaborne <an...@apache.org>
> To:
> dev@jena.apache.org
> Date:
> 06/08/2012 04:07 PM
> Subject:
> Re: Release 2.7.1
>
>
>
> On 08/06/12 19:55, Simon Helsen wrote:
> > hi again,
> >
> > k, so, it is tricky to distill a test case out of our framework because
> > this one is based on multiple threads, but I am debugging it myself
> > instead.
> >
> > So, I put the breakpoint in DatasetControlMRSW.policyError where the cme
> > is thrown. When I do that and rerun the test suite, I get into a
> scenario
> > where 4 threads hang on the breakpoint. 3 of these are 'read' threads
> and
> > 1 is a 'write' thread. Now, the writeCounter says it has 4 (and the
> > readCounter is 0), which is why the cme is thrown. So, the question is
> why
> > the writeCounter says 4.
> >
> > In order to find that out, I set a different breakpoint at startUpdate
> in
> > DatasetControlMRSW. I notice that it came from a query, i.e. a READ
> > transaction. The violating code is this:
> >
> >
> > @Override
> > protected void _begin(ReadWrite readWrite)
> > {
> > synchronized(lock)
> > {
> > if ( ! haveUsedInTransaction )
> > getBaseDatasetGraph().sync() ;
> > haveUsedInTransaction = true ;
> > DatasetGraphTxn dsgTxn = sConn.begin(readWrite) ;
> > txn.set(dsgTxn) ;
> > inTransaction.set(true) ;
> > }
> > }
> >
> >
> > The bit
> >
> > if ( ! haveUsedInTransaction )
> > getBaseDatasetGraph().sync() ;
> >
> > is the problem. It calls prefixes.sync() which calls
> nodeTupleTable.sync()
> > which calls startWrite() ;
> >
> > any ideas how to fix this?
> >
> > Simon
>
>
> sync's are writes.
>
> It's making sure that any non-transactional changes are put to disk
> before the whole thing swicths into transactional mode. Not a usage to
> be encouraged but the code needs to be safe.
>
>
> It's hard to tell without how the DatasetGraphTransaction's get made but
> try changing
>
> synchronized(lock)
>
> to
>
> synchronized(sConn)
>
> (the test suite passes - not surprising as it is a more conservative
> choice than the built code.)
>
> It's late here - but that might be the cause. Otherwise, how are the
> dataset being made? There seem to be several about - that should be OK,
> as should multiple threads per DatasetGraphTransaction (transactions are
> per thread). Which style are you using?
>
> Andy
>
>
>
>
>
>
Re: Release 2.7.1
Posted by Simon Helsen <sh...@ca.ibm.com>.
that seems to work. So the lock attribute is useless now. I am not
entirely sure why this fixes things since I cannot see anyone else
synchronizing on sConn, but I assume that happens somewhere outside.
I added a comment to https://issues.apache.org/jira/browse/JENA-252
From:
Simon Helsen/Toronto/IBM@IBMCA
To:
dev@jena.apache.org
Cc:
Andy Seaborne <an...@gmail.com>, dev@jena.apache.org
Date:
06/08/2012 05:01 PM
Subject:
Re: Release 2.7.1
I'll try the proposed fix.
If you can tell me what you're looking for, I can debug this further. What
exactly do you mean by "It's hard to tell without how the
DatasetGraphTransaction's get made"?
As for the style, I followed the documentation on multiple threads, so I
create a dataset for each transaction and close it. A transaction is
unique per thread, i.e. not shared as recommended. You saw the model
already in the test I provide for 250, so we have something like this
private <E> E storeOperation(String query, QueryActivity<E>
queryActivity) {
Dataset dataset = TDBFactory.createDataset(this.location);
QueryExecution qe = null;
try {
dataset.begin(ReadWrite.READ) ;
qe = QueryExecutionFactory.create(query, dataset);
E e = queryActivity.run(qe);
dataset.commit();
return e;
} catch (Throwable e) {
dataset.abort();
throw new RuntimeException(e);
} finally {
try {
if (qe != null) {
qe.close();
}
} finally {
dataset.end();
}
}
}
for a query - and FYI, we do not allow update queries. There are some
other variations of this for type of reads, but in my test case it looks
like this is the one being used by the read transactions. Then we use this
one for writes:
private <E> E storeOperation(String graphName, ModelWriteActivity<E>
modelWriteActivity) {
Dataset dataset = TDBFactory.createDataset(this.location);
try {
dataset.begin(ReadWrite.WRITE);
Model m = dataset.getNamedModel(graphName);
E e = modelWriteActivity.run(m);
dataset.commit();
return e;
} catch (Throwable e) {
dataset.abort();
throw new RuntimeException(e);
} finally {
dataset.end();
}
}
and we have one for multiple models per transaction. Each of these are
executed within their own thread. The dataset is (obviously) never shared
Simon
From:
Andy Seaborne <an...@apache.org>
To:
dev@jena.apache.org
Date:
06/08/2012 04:07 PM
Subject:
Re: Release 2.7.1
On 08/06/12 19:55, Simon Helsen wrote:
> hi again,
>
> k, so, it is tricky to distill a test case out of our framework because
> this one is based on multiple threads, but I am debugging it myself
> instead.
>
> So, I put the breakpoint in DatasetControlMRSW.policyError where the cme
> is thrown. When I do that and rerun the test suite, I get into a
scenario
> where 4 threads hang on the breakpoint. 3 of these are 'read' threads
and
> 1 is a 'write' thread. Now, the writeCounter says it has 4 (and the
> readCounter is 0), which is why the cme is thrown. So, the question is
why
> the writeCounter says 4.
>
> In order to find that out, I set a different breakpoint at startUpdate
in
> DatasetControlMRSW. I notice that it came from a query, i.e. a READ
> transaction. The violating code is this:
>
>
> @Override
> protected void _begin(ReadWrite readWrite)
> {
> synchronized(lock)
> {
> if ( ! haveUsedInTransaction )
> getBaseDatasetGraph().sync() ;
> haveUsedInTransaction = true ;
> DatasetGraphTxn dsgTxn = sConn.begin(readWrite) ;
> txn.set(dsgTxn) ;
> inTransaction.set(true) ;
> }
> }
>
>
> The bit
>
> if ( ! haveUsedInTransaction )
> getBaseDatasetGraph().sync() ;
>
> is the problem. It calls prefixes.sync() which calls
nodeTupleTable.sync()
> which calls startWrite() ;
>
> any ideas how to fix this?
>
> Simon
sync's are writes.
It's making sure that any non-transactional changes are put to disk
before the whole thing swicths into transactional mode. Not a usage to
be encouraged but the code needs to be safe.
It's hard to tell without how the DatasetGraphTransaction's get made but
try changing
synchronized(lock)
to
synchronized(sConn)
(the test suite passes - not surprising as it is a more conservative
choice than the built code.)
It's late here - but that might be the cause. Otherwise, how are the
dataset being made? There seem to be several about - that should be OK,
as should multiple threads per DatasetGraphTransaction (transactions are
per thread). Which style are you using?
Andy
Re: Release 2.7.1
Posted by Simon Helsen <sh...@ca.ibm.com>.
I'll try the proposed fix.
If you can tell me what you're looking for, I can debug this further. What
exactly do you mean by "It's hard to tell without how the
DatasetGraphTransaction's get made"?
As for the style, I followed the documentation on multiple threads, so I
create a dataset for each transaction and close it. A transaction is
unique per thread, i.e. not shared as recommended. You saw the model
already in the test I provide for 250, so we have something like this
private <E> E storeOperation(String query, QueryActivity<E>
queryActivity) {
Dataset dataset = TDBFactory.createDataset(this.location);
QueryExecution qe = null;
try {
dataset.begin(ReadWrite.READ) ;
qe = QueryExecutionFactory.create(query, dataset);
E e = queryActivity.run(qe);
dataset.commit();
return e;
} catch (Throwable e) {
dataset.abort();
throw new RuntimeException(e);
} finally {
try {
if (qe != null) {
qe.close();
}
} finally {
dataset.end();
}
}
}
for a query - and FYI, we do not allow update queries. There are some
other variations of this for type of reads, but in my test case it looks
like this is the one being used by the read transactions. Then we use this
one for writes:
private <E> E storeOperation(String graphName, ModelWriteActivity<E>
modelWriteActivity) {
Dataset dataset = TDBFactory.createDataset(this.location);
try {
dataset.begin(ReadWrite.WRITE);
Model m = dataset.getNamedModel(graphName);
E e = modelWriteActivity.run(m);
dataset.commit();
return e;
} catch (Throwable e) {
dataset.abort();
throw new RuntimeException(e);
} finally {
dataset.end();
}
}
and we have one for multiple models per transaction. Each of these are
executed within their own thread. The dataset is (obviously) never shared
Simon
From:
Andy Seaborne <an...@apache.org>
To:
dev@jena.apache.org
Date:
06/08/2012 04:07 PM
Subject:
Re: Release 2.7.1
On 08/06/12 19:55, Simon Helsen wrote:
> hi again,
>
> k, so, it is tricky to distill a test case out of our framework because
> this one is based on multiple threads, but I am debugging it myself
> instead.
>
> So, I put the breakpoint in DatasetControlMRSW.policyError where the cme
> is thrown. When I do that and rerun the test suite, I get into a
scenario
> where 4 threads hang on the breakpoint. 3 of these are 'read' threads
and
> 1 is a 'write' thread. Now, the writeCounter says it has 4 (and the
> readCounter is 0), which is why the cme is thrown. So, the question is
why
> the writeCounter says 4.
>
> In order to find that out, I set a different breakpoint at startUpdate
in
> DatasetControlMRSW. I notice that it came from a query, i.e. a READ
> transaction. The violating code is this:
>
>
> @Override
> protected void _begin(ReadWrite readWrite)
> {
> synchronized(lock)
> {
> if ( ! haveUsedInTransaction )
> getBaseDatasetGraph().sync() ;
> haveUsedInTransaction = true ;
> DatasetGraphTxn dsgTxn = sConn.begin(readWrite) ;
> txn.set(dsgTxn) ;
> inTransaction.set(true) ;
> }
> }
>
>
> The bit
>
> if ( ! haveUsedInTransaction )
> getBaseDatasetGraph().sync() ;
>
> is the problem. It calls prefixes.sync() which calls
nodeTupleTable.sync()
> which calls startWrite() ;
>
> any ideas how to fix this?
>
> Simon
sync's are writes.
It's making sure that any non-transactional changes are put to disk
before the whole thing swicths into transactional mode. Not a usage to
be encouraged but the code needs to be safe.
It's hard to tell without how the DatasetGraphTransaction's get made but
try changing
synchronized(lock)
to
synchronized(sConn)
(the test suite passes - not surprising as it is a more conservative
choice than the built code.)
It's late here - but that might be the cause. Otherwise, how are the
dataset being made? There seem to be several about - that should be OK,
as should multiple threads per DatasetGraphTransaction (transactions are
per thread). Which style are you using?
Andy
Re: Release 2.7.1
Posted by Andy Seaborne <an...@apache.org>.
On 08/06/12 19:55, Simon Helsen wrote:
> hi again,
>
> k, so, it is tricky to distill a test case out of our framework because
> this one is based on multiple threads, but I am debugging it myself
> instead.
>
> So, I put the breakpoint in DatasetControlMRSW.policyError where the cme
> is thrown. When I do that and rerun the test suite, I get into a scenario
> where 4 threads hang on the breakpoint. 3 of these are 'read' threads and
> 1 is a 'write' thread. Now, the writeCounter says it has 4 (and the
> readCounter is 0), which is why the cme is thrown. So, the question is why
> the writeCounter says 4.
>
> In order to find that out, I set a different breakpoint at startUpdate in
> DatasetControlMRSW. I notice that it came from a query, i.e. a READ
> transaction. The violating code is this:
>
>
> @Override
> protected void _begin(ReadWrite readWrite)
> {
> synchronized(lock)
> {
> if ( ! haveUsedInTransaction )
> getBaseDatasetGraph().sync() ;
> haveUsedInTransaction = true ;
> DatasetGraphTxn dsgTxn = sConn.begin(readWrite) ;
> txn.set(dsgTxn) ;
> inTransaction.set(true) ;
> }
> }
>
>
> The bit
>
> if ( ! haveUsedInTransaction )
> getBaseDatasetGraph().sync() ;
>
> is the problem. It calls prefixes.sync() which calls nodeTupleTable.sync()
> which calls startWrite() ;
>
> any ideas how to fix this?
>
> Simon
sync's are writes.
It's making sure that any non-transactional changes are put to disk
before the whole thing swicths into transactional mode. Not a usage to
be encouraged but the code needs to be safe.
It's hard to tell without how the DatasetGraphTransaction's get made but
try changing
synchronized(lock)
to
synchronized(sConn)
(the test suite passes - not surprising as it is a more conservative
choice than the built code.)
It's late here - but that might be the cause. Otherwise, how are the
dataset being made? There seem to be several about - that should be OK,
as should multiple threads per DatasetGraphTransaction (transactions are
per thread). Which style are you using?
Andy
Re: Release 2.7.1
Posted by Simon Helsen <sh...@ca.ibm.com>.
hi again,
k, so, it is tricky to distill a test case out of our framework because
this one is based on multiple threads, but I am debugging it myself
instead.
So, I put the breakpoint in DatasetControlMRSW.policyError where the cme
is thrown. When I do that and rerun the test suite, I get into a scenario
where 4 threads hang on the breakpoint. 3 of these are 'read' threads and
1 is a 'write' thread. Now, the writeCounter says it has 4 (and the
readCounter is 0), which is why the cme is thrown. So, the question is why
the writeCounter says 4.
In order to find that out, I set a different breakpoint at startUpdate in
DatasetControlMRSW. I notice that it came from a query, i.e. a READ
transaction. The violating code is this:
@Override
protected void _begin(ReadWrite readWrite)
{
synchronized(lock)
{
if ( ! haveUsedInTransaction )
getBaseDatasetGraph().sync() ;
haveUsedInTransaction = true ;
DatasetGraphTxn dsgTxn = sConn.begin(readWrite) ;
txn.set(dsgTxn) ;
inTransaction.set(true) ;
}
}
The bit
if ( ! haveUsedInTransaction )
getBaseDatasetGraph().sync() ;
is the problem. It calls prefixes.sync() which calls nodeTupleTable.sync()
which calls startWrite() ;
any ideas how to fix this?
Simon
From:
Simon Helsen/Toronto/IBM@IBMCA
To:
dev@jena.apache.org
Cc:
dev@jena.apache.org
Date:
06/08/2012 02:09 PM
Subject:
Re: Release 2.7.1
btw, that is the first exception I see. After that, I see different other
exceptions, but I suspect they are a consequence of this one
e.g.
Caused by: java.lang.NullPointerException
at com.hp.hpl.jena.tdb.transaction.DatasetGraphTransaction._end(
DatasetGraphTransaction.java:168)
at com.hp.hpl.jena.tdb.migrate.DatasetGraphTrackActive.end(
DatasetGraphTrackActive.java:76)
at com.hp.hpl.jena.sparql.core.DatasetImpl.end(
DatasetImpl.java:159)
at
com.ibm.team.jfs.rdf.internal.jena.tdb.JenaTxTdbProvider.storeOperation(
JenaTxTdbProvider.java:196)
at com.ibm.team.jfs.rdf.internal.jena.tdb.JenaTxTdbProvider.query(
JenaTxTdbProvider.java:1573)
... 39 more
From:
Simon Helsen/Toronto/IBM@IBMCA
To:
dev@jena.apache.org
Cc:
"dev@jena.apache.org" <de...@jena.apache.org>
Date:
06/08/2012 02:00 PM
Subject:
Re: Release 2.7.1
Andy,
since your latest fix, I am running into another serious error I have not
seen before. It is possible that the problem is on our end - I will
investigate, but since I didn't touch any code, I am rather worried the
issue is related to your fix for 250.
I would rather have you hold off 2.7.1 and make sure things are ok.
I know you need test cases etc, but let me already provide a stack trace
to show the seriousness of the problem
Simon
13:01:36,504 [273813586@qtp-2076933067-43] ERROR com.ibm.team.jfs -
Originating Exception:
java.util.ConcurrentModificationException: Reader = 0, Writer = 2
at com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.policyError(
DatasetControlMRSW.java:157)
at com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.policyError(
DatasetControlMRSW.java:152)
at com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.checkConcurrency(
DatasetControlMRSW.java:81)
at com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.startUpdate(
DatasetControlMRSW.java:60)
at
com.hp.hpl.jena.tdb.nodetable.NodeTupleTableConcrete.startWrite(
NodeTupleTableConcrete.java:64)
at com.hp.hpl.jena.tdb.nodetable.NodeTupleTableConcrete.sync(
NodeTupleTableConcrete.java:255)
at com.hp.hpl.jena.tdb.store.DatasetPrefixesTDB.sync(
DatasetPrefixesTDB.java:235)
at com.hp.hpl.jena.tdb.store.DatasetGraphTDB.sync(
DatasetGraphTDB.java:283)
at com.hp.hpl.jena.tdb.transaction.DatasetGraphTransaction._begin(
DatasetGraphTransaction.java:143)
at com.hp.hpl.jena.tdb.migrate.DatasetGraphTrackActive.begin(
DatasetGraphTrackActive.java:52)
at com.hp.hpl.jena.sparql.core.DatasetImpl.begin(
DatasetImpl.java:126)
at
com.ibm.team.jfs.rdf.internal.jena.tdb.JenaTxTdbProvider.storeOperation(
JenaTxTdbProvider.java:183)
at com.ibm.team.jfs.rdf.internal.jena.tdb.JenaTxTdbProvider.query(
JenaTxTdbProvider.java:1573)
at
com.ibm.team.jfs.rdf.internal.jena.JenaQueryService.performQuery(
JenaQueryService.java:511)
at
com.ibm.team.jfs.rdf.internal.jena.JenaQueryService.perform_GET(
JenaQueryService.java:225)
at com.ibm.team.repository.service.TeamRawService.service(
TeamRawService.java:82)
at sun.reflect.GeneratedMethodAccessor221.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at
org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord.invoke(
ExportProxyServiceRecord.java:361)
at
org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord.access$0(
ExportProxyServiceRecord.java:347)
at
org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord$ExportedServiceInvocationHandler.invoke(
ExportProxyServiceRecord.java:56)
at $Proxy21075.service(Unknown Source)
at
com.ibm.team.repository.servlet.AbstractTeamServerServlet.doRestService(
AbstractTeamServerServlet.java:872)
at
com.ibm.team.repository.servlet.AbstractTeamServerServlet.handleRequest2(
AbstractTeamServerServlet.java:2054)
at
com.ibm.team.repository.servlet.AbstractTeamServerServlet.handleRequest(
AbstractTeamServerServlet.java:1878)
at
com.ibm.team.repository.servlet.AbstractTeamServerServlet.access$0(
AbstractTeamServerServlet.java:1863)
at
com.ibm.team.repository.servlet.AbstractTeamServerServlet$1.service(
AbstractTeamServerServlet.java:208)
at
com.ibm.team.repository.service.internal.oauth.OAuthServiceProvider$3.run(
OAuthServiceProvider.java:763)
at
com.ibm.team.repository.servlet.AbstractTeamServerServlet.service(
AbstractTeamServerServlet.java:1682)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.eclipse.equinox.http.registry.internal.ServletManager$ServletWrapper.service(
ServletManager.java:180)
at
org.eclipse.equinox.http.servlet.internal.ServletRegistration.service(
ServletRegistration.java:61)
at
org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(
ProxyServlet.java:126)
at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(
ProxyServlet.java:76)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(
ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler.handle(
ServletHandler.java:390)
at org.mortbay.jetty.security.SecurityHandler.handle(
SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(
SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(
ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(
WebAppContext.java:418)
at org.mortbay.jetty.handler.HandlerWrapper.handle(
HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(
HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(
HttpConnection.java:924)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212
)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404
)
at org.mortbay.jetty.bio.SocketConnector$Connection.run(
SocketConnector.java:228)
at
org.mortbay.jetty.security.SslSocketConnector$SslConnection.run(
SslSocketConnector.java:680)
From:
Rob Vesse <rv...@yarcdata.com>
To:
"dev@jena.apache.org" <de...@jena.apache.org>
Date:
06/08/2012 01:04 PM
Subject:
Re: Release 2.7.1
Thanks for pushing forward on this Andy, I wish I had more time to do
stuff on Jena at the moment as there's bits and pieces that I'd like to
work on (e.g. Streaming parsing on SPARQL JSON, war-ifying Fuseki etc)
that I don't have the cycles for right now
Thanks for all the work
Rob
On 6/8/12 9:54 AM, "Andy Seaborne" <an...@apache.org> wrote:
>With the (hopeful) resolution of JENA-250, I have rebuilt the
>pre-release binaries:
>
>http://people.apache.org/~andy/Jena-2.7.1/
>
>apache-jena-2.7.1-SNAPSHOT.zip
>jena-2.7.1-SNAPSHOT-source-release.zip
>jena-fuseki-0.2.2-SNAPSHOT-distribution.zip
>
>At this point, I have one oddity I noticed in TDB I want to investigate
>- this is probably nothing more than me not remembering how the
>transactional node table actually works.
>
>Other than that I will do the formal build and call the vote. Even if
>something in TDB is not optimal, I am very unlikely to change anything
>at this stage. It is better to go with deployment-tested code than with
>an "improvement" then test out changes and issue an incremental release
>quite soon.
>
> Andy
Re: Release 2.7.1
Posted by Simon Helsen <sh...@ca.ibm.com>.
btw, that is the first exception I see. After that, I see different other
exceptions, but I suspect they are a consequence of this one
e.g.
Caused by: java.lang.NullPointerException
at com.hp.hpl.jena.tdb.transaction.DatasetGraphTransaction._end(
DatasetGraphTransaction.java:168)
at com.hp.hpl.jena.tdb.migrate.DatasetGraphTrackActive.end(
DatasetGraphTrackActive.java:76)
at com.hp.hpl.jena.sparql.core.DatasetImpl.end(
DatasetImpl.java:159)
at
com.ibm.team.jfs.rdf.internal.jena.tdb.JenaTxTdbProvider.storeOperation(
JenaTxTdbProvider.java:196)
at com.ibm.team.jfs.rdf.internal.jena.tdb.JenaTxTdbProvider.query(
JenaTxTdbProvider.java:1573)
... 39 more
From:
Simon Helsen/Toronto/IBM@IBMCA
To:
dev@jena.apache.org
Cc:
"dev@jena.apache.org" <de...@jena.apache.org>
Date:
06/08/2012 02:00 PM
Subject:
Re: Release 2.7.1
Andy,
since your latest fix, I am running into another serious error I have not
seen before. It is possible that the problem is on our end - I will
investigate, but since I didn't touch any code, I am rather worried the
issue is related to your fix for 250.
I would rather have you hold off 2.7.1 and make sure things are ok.
I know you need test cases etc, but let me already provide a stack trace
to show the seriousness of the problem
Simon
13:01:36,504 [273813586@qtp-2076933067-43] ERROR com.ibm.team.jfs -
Originating Exception:
java.util.ConcurrentModificationException: Reader = 0, Writer = 2
at com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.policyError(
DatasetControlMRSW.java:157)
at com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.policyError(
DatasetControlMRSW.java:152)
at com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.checkConcurrency(
DatasetControlMRSW.java:81)
at com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.startUpdate(
DatasetControlMRSW.java:60)
at
com.hp.hpl.jena.tdb.nodetable.NodeTupleTableConcrete.startWrite(
NodeTupleTableConcrete.java:64)
at com.hp.hpl.jena.tdb.nodetable.NodeTupleTableConcrete.sync(
NodeTupleTableConcrete.java:255)
at com.hp.hpl.jena.tdb.store.DatasetPrefixesTDB.sync(
DatasetPrefixesTDB.java:235)
at com.hp.hpl.jena.tdb.store.DatasetGraphTDB.sync(
DatasetGraphTDB.java:283)
at com.hp.hpl.jena.tdb.transaction.DatasetGraphTransaction._begin(
DatasetGraphTransaction.java:143)
at com.hp.hpl.jena.tdb.migrate.DatasetGraphTrackActive.begin(
DatasetGraphTrackActive.java:52)
at com.hp.hpl.jena.sparql.core.DatasetImpl.begin(
DatasetImpl.java:126)
at
com.ibm.team.jfs.rdf.internal.jena.tdb.JenaTxTdbProvider.storeOperation(
JenaTxTdbProvider.java:183)
at com.ibm.team.jfs.rdf.internal.jena.tdb.JenaTxTdbProvider.query(
JenaTxTdbProvider.java:1573)
at
com.ibm.team.jfs.rdf.internal.jena.JenaQueryService.performQuery(
JenaQueryService.java:511)
at
com.ibm.team.jfs.rdf.internal.jena.JenaQueryService.perform_GET(
JenaQueryService.java:225)
at com.ibm.team.repository.service.TeamRawService.service(
TeamRawService.java:82)
at sun.reflect.GeneratedMethodAccessor221.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at
org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord.invoke(
ExportProxyServiceRecord.java:361)
at
org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord.access$0(
ExportProxyServiceRecord.java:347)
at
org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord$ExportedServiceInvocationHandler.invoke(
ExportProxyServiceRecord.java:56)
at $Proxy21075.service(Unknown Source)
at
com.ibm.team.repository.servlet.AbstractTeamServerServlet.doRestService(
AbstractTeamServerServlet.java:872)
at
com.ibm.team.repository.servlet.AbstractTeamServerServlet.handleRequest2(
AbstractTeamServerServlet.java:2054)
at
com.ibm.team.repository.servlet.AbstractTeamServerServlet.handleRequest(
AbstractTeamServerServlet.java:1878)
at
com.ibm.team.repository.servlet.AbstractTeamServerServlet.access$0(
AbstractTeamServerServlet.java:1863)
at
com.ibm.team.repository.servlet.AbstractTeamServerServlet$1.service(
AbstractTeamServerServlet.java:208)
at
com.ibm.team.repository.service.internal.oauth.OAuthServiceProvider$3.run(
OAuthServiceProvider.java:763)
at
com.ibm.team.repository.servlet.AbstractTeamServerServlet.service(
AbstractTeamServerServlet.java:1682)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.eclipse.equinox.http.registry.internal.ServletManager$ServletWrapper.service(
ServletManager.java:180)
at
org.eclipse.equinox.http.servlet.internal.ServletRegistration.service(
ServletRegistration.java:61)
at
org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(
ProxyServlet.java:126)
at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(
ProxyServlet.java:76)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(
ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler.handle(
ServletHandler.java:390)
at org.mortbay.jetty.security.SecurityHandler.handle(
SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(
SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(
ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(
WebAppContext.java:418)
at org.mortbay.jetty.handler.HandlerWrapper.handle(
HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(
HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(
HttpConnection.java:924)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212
)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404
)
at org.mortbay.jetty.bio.SocketConnector$Connection.run(
SocketConnector.java:228)
at
org.mortbay.jetty.security.SslSocketConnector$SslConnection.run(
SslSocketConnector.java:680)
From:
Rob Vesse <rv...@yarcdata.com>
To:
"dev@jena.apache.org" <de...@jena.apache.org>
Date:
06/08/2012 01:04 PM
Subject:
Re: Release 2.7.1
Thanks for pushing forward on this Andy, I wish I had more time to do
stuff on Jena at the moment as there's bits and pieces that I'd like to
work on (e.g. Streaming parsing on SPARQL JSON, war-ifying Fuseki etc)
that I don't have the cycles for right now
Thanks for all the work
Rob
On 6/8/12 9:54 AM, "Andy Seaborne" <an...@apache.org> wrote:
>With the (hopeful) resolution of JENA-250, I have rebuilt the
>pre-release binaries:
>
>http://people.apache.org/~andy/Jena-2.7.1/
>
>apache-jena-2.7.1-SNAPSHOT.zip
>jena-2.7.1-SNAPSHOT-source-release.zip
>jena-fuseki-0.2.2-SNAPSHOT-distribution.zip
>
>At this point, I have one oddity I noticed in TDB I want to investigate
>- this is probably nothing more than me not remembering how the
>transactional node table actually works.
>
>Other than that I will do the formal build and call the vote. Even if
>something in TDB is not optimal, I am very unlikely to change anything
>at this stage. It is better to go with deployment-tested code than with
>an "improvement" then test out changes and issue an incremental release
>quite soon.
>
> Andy
Re: Release 2.7.1
Posted by Simon Helsen <sh...@ca.ibm.com>.
Andy,
since your latest fix, I am running into another serious error I have not
seen before. It is possible that the problem is on our end - I will
investigate, but since I didn't touch any code, I am rather worried the
issue is related to your fix for 250.
I would rather have you hold off 2.7.1 and make sure things are ok.
I know you need test cases etc, but let me already provide a stack trace
to show the seriousness of the problem
Simon
13:01:36,504 [273813586@qtp-2076933067-43] ERROR com.ibm.team.jfs -
Originating Exception:
java.util.ConcurrentModificationException: Reader = 0, Writer = 2
at com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.policyError(
DatasetControlMRSW.java:157)
at com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.policyError(
DatasetControlMRSW.java:152)
at com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.checkConcurrency(
DatasetControlMRSW.java:81)
at com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.startUpdate(
DatasetControlMRSW.java:60)
at
com.hp.hpl.jena.tdb.nodetable.NodeTupleTableConcrete.startWrite(
NodeTupleTableConcrete.java:64)
at com.hp.hpl.jena.tdb.nodetable.NodeTupleTableConcrete.sync(
NodeTupleTableConcrete.java:255)
at com.hp.hpl.jena.tdb.store.DatasetPrefixesTDB.sync(
DatasetPrefixesTDB.java:235)
at com.hp.hpl.jena.tdb.store.DatasetGraphTDB.sync(
DatasetGraphTDB.java:283)
at com.hp.hpl.jena.tdb.transaction.DatasetGraphTransaction._begin(
DatasetGraphTransaction.java:143)
at com.hp.hpl.jena.tdb.migrate.DatasetGraphTrackActive.begin(
DatasetGraphTrackActive.java:52)
at com.hp.hpl.jena.sparql.core.DatasetImpl.begin(
DatasetImpl.java:126)
at
com.ibm.team.jfs.rdf.internal.jena.tdb.JenaTxTdbProvider.storeOperation(
JenaTxTdbProvider.java:183)
at com.ibm.team.jfs.rdf.internal.jena.tdb.JenaTxTdbProvider.query(
JenaTxTdbProvider.java:1573)
at
com.ibm.team.jfs.rdf.internal.jena.JenaQueryService.performQuery(
JenaQueryService.java:511)
at
com.ibm.team.jfs.rdf.internal.jena.JenaQueryService.perform_GET(
JenaQueryService.java:225)
at com.ibm.team.repository.service.TeamRawService.service(
TeamRawService.java:82)
at sun.reflect.GeneratedMethodAccessor221.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at
org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord.invoke(
ExportProxyServiceRecord.java:361)
at
org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord.access$0(
ExportProxyServiceRecord.java:347)
at
org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord$ExportedServiceInvocationHandler.invoke(
ExportProxyServiceRecord.java:56)
at $Proxy21075.service(Unknown Source)
at
com.ibm.team.repository.servlet.AbstractTeamServerServlet.doRestService(
AbstractTeamServerServlet.java:872)
at
com.ibm.team.repository.servlet.AbstractTeamServerServlet.handleRequest2(
AbstractTeamServerServlet.java:2054)
at
com.ibm.team.repository.servlet.AbstractTeamServerServlet.handleRequest(
AbstractTeamServerServlet.java:1878)
at
com.ibm.team.repository.servlet.AbstractTeamServerServlet.access$0(
AbstractTeamServerServlet.java:1863)
at
com.ibm.team.repository.servlet.AbstractTeamServerServlet$1.service(
AbstractTeamServerServlet.java:208)
at
com.ibm.team.repository.service.internal.oauth.OAuthServiceProvider$3.run(
OAuthServiceProvider.java:763)
at
com.ibm.team.repository.servlet.AbstractTeamServerServlet.service(
AbstractTeamServerServlet.java:1682)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.eclipse.equinox.http.registry.internal.ServletManager$ServletWrapper.service(
ServletManager.java:180)
at
org.eclipse.equinox.http.servlet.internal.ServletRegistration.service(
ServletRegistration.java:61)
at
org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(
ProxyServlet.java:126)
at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(
ProxyServlet.java:76)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(
ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler.handle(
ServletHandler.java:390)
at org.mortbay.jetty.security.SecurityHandler.handle(
SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(
SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(
ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(
WebAppContext.java:418)
at org.mortbay.jetty.handler.HandlerWrapper.handle(
HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(
HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(
HttpConnection.java:924)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212
)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404
)
at org.mortbay.jetty.bio.SocketConnector$Connection.run(
SocketConnector.java:228)
at
org.mortbay.jetty.security.SslSocketConnector$SslConnection.run(
SslSocketConnector.java:680)
From:
Rob Vesse <rv...@yarcdata.com>
To:
"dev@jena.apache.org" <de...@jena.apache.org>
Date:
06/08/2012 01:04 PM
Subject:
Re: Release 2.7.1
Thanks for pushing forward on this Andy, I wish I had more time to do
stuff on Jena at the moment as there's bits and pieces that I'd like to
work on (e.g. Streaming parsing on SPARQL JSON, war-ifying Fuseki etc)
that I don't have the cycles for right now
Thanks for all the work
Rob
On 6/8/12 9:54 AM, "Andy Seaborne" <an...@apache.org> wrote:
>With the (hopeful) resolution of JENA-250, I have rebuilt the
>pre-release binaries:
>
>http://people.apache.org/~andy/Jena-2.7.1/
>
>apache-jena-2.7.1-SNAPSHOT.zip
>jena-2.7.1-SNAPSHOT-source-release.zip
>jena-fuseki-0.2.2-SNAPSHOT-distribution.zip
>
>At this point, I have one oddity I noticed in TDB I want to investigate
>- this is probably nothing more than me not remembering how the
>transactional node table actually works.
>
>Other than that I will do the formal build and call the vote. Even if
>something in TDB is not optimal, I am very unlikely to change anything
>at this stage. It is better to go with deployment-tested code than with
>an "improvement" then test out changes and issue an incremental release
>quite soon.
>
> Andy
Re: Release 2.7.1
Posted by Rob Vesse <rv...@yarcdata.com>.
Thanks for pushing forward on this Andy, I wish I had more time to do
stuff on Jena at the moment as there's bits and pieces that I'd like to
work on (e.g. Streaming parsing on SPARQL JSON, war-ifying Fuseki etc)
that I don't have the cycles for right now
Thanks for all the work
Rob
On 6/8/12 9:54 AM, "Andy Seaborne" <an...@apache.org> wrote:
>With the (hopeful) resolution of JENA-250, I have rebuilt the
>pre-release binaries:
>
>http://people.apache.org/~andy/Jena-2.7.1/
>
>apache-jena-2.7.1-SNAPSHOT.zip
>jena-2.7.1-SNAPSHOT-source-release.zip
>jena-fuseki-0.2.2-SNAPSHOT-distribution.zip
>
>At this point, I have one oddity I noticed in TDB I want to investigate
>- this is probably nothing more than me not remembering how the
>transactional node table actually works.
>
>Other than that I will do the formal build and call the vote. Even if
>something in TDB is not optimal, I am very unlikely to change anything
>at this stage. It is better to go with deployment-tested code than with
>an "improvement" then test out changes and issue an incremental release
>quite soon.
>
> Andy
Re: Release 2.7.1
Posted by Andy Seaborne <an...@apache.org>.
With the (hopeful) resolution of JENA-250, I have rebuilt the
pre-release binaries:
http://people.apache.org/~andy/Jena-2.7.1/
apache-jena-2.7.1-SNAPSHOT.zip
jena-2.7.1-SNAPSHOT-source-release.zip
jena-fuseki-0.2.2-SNAPSHOT-distribution.zip
At this point, I have one oddity I noticed in TDB I want to investigate
- this is probably nothing more than me not remembering how the
transactional node table actually works.
Other than that I will do the formal build and call the vote. Even if
something in TDB is not optimal, I am very unlikely to change anything
at this stage. It is better to go with deployment-tested code than with
an "improvement" then test out changes and issue an incremental release
quite soon.
Andy
Re: Release 2.7.1
Posted by Andy Seaborne <an...@apache.org>.
>> - why is there a log4j.properties in the root folder if there is
>> jena-log4j.properties in jena-core-2.7.1-SNAPSHOT.jar?
>
> Reopened JENA-36 - some commands don't work if log4j.properties removed
> and the handling of jena-log4j.properties is dubious.
The file in the top of the distribution directory is used scripts to
configure log4j for the commands.
In the interests of safety close to a release I have left the mechanism
in place, but renamed the file jena-log4j.properties.
In addition, running commands directly, with "java -cp lib/* ..." will
initialize some sort of log4j setup so no warning is issued even if
running without a script wrapper.
Andy
Re: Release 2.7.1
Posted by Andy Seaborne <an...@apache.org>.
Thorsten,
Thanks for the checking.
On 01/06/12 15:19, Möller Thorsten wrote:
>
> Am 01.06.2012 um 15:26 schrieb Andy Seaborne:
>
>> I've uploaded the three zip files that the build produces (not done as a maven release, just built against trunk) for inspection.
>>
>> http://people.apache.org/~andy/Jena-2.7.1/
>>
>> apache-jena-2.7.1-SNAPSHOT.zip
>
> All probably minor:
> - there is ReleaseNotes-Fuseki.txt, but not Fuseki itself
Done.
(renamed all "ChangeLog" to "ReleaseNotes", remove putting the Fuseki
one in the apache-jena binary)
> - ReleaseNotes-Jena.txt mentions removal of ICU4J --> should also refer to JENA-177
Done.
> - JavaDoc index page mentions the version number for jena-arq and jena-tdb, but not for jena-core
Much fixing of javadoc production.
> - why is there a log4j.properties in the root folder if there is jena-log4j.properties in jena-core-2.7.1-SNAPSHOT.jar?
Reopened JENA-36 - some commands don't work if log4j.properties removed
and the handling of jena-log4j.properties is dubious.
> - is the SVN URL "http://svn.apache.org/repos/asf//jena/" in README correct (asf//jena)?
Fixed.
Andy
Re: Release 2.7.1
Posted by Möller Thorsten <th...@unibas.ch>.
Am 01.06.2012 um 15:26 schrieb Andy Seaborne:
> I've uploaded the three zip files that the build produces (not done as a maven release, just built against trunk) for inspection.
>
> http://people.apache.org/~andy/Jena-2.7.1/
>
> apache-jena-2.7.1-SNAPSHOT.zip
All probably minor:
- there is ReleaseNotes-Fuseki.txt, but not Fuseki itself
- ReleaseNotes-Jena.txt mentions removal of ICU4J --> should also refer to JENA-177
- JavaDoc index page mentions the version number for jena-arq and jena-tdb, but not for jena-core
- why is there a log4j.properties in the root folder if there is jena-log4j.properties in jena-core-2.7.1-SNAPSHOT.jar?
- is the SVN URL "http://svn.apache.org/repos/asf//jena/" in README correct (asf//jena)?
> jena-2.7.1-SNAPSHOT-source-release.zip
> jena-fuseki-0.2.2-SNAPSHOT-distribution.zip
havn't checked these files
Thorsten