Re: ConcurrentModificationException using RDFLanguages.getRegisteredLanguages()
I know. I have no explanation. Maybe the NetBeans are messing with me.
On Wed, Jul 1, 2020 at 2:52 PM Andy Seaborne wrote:
>
>
>
> On 01/07/2020 09:58, Martynas Jusevičius wrote:
> > Thanks.
> >
> > What jar is missing though? I have apache-jena-libs as a dependency. I
> > can see it includes TDB and TDB2.
>
> And ARQ - but that disagrees with the error you are seeing:
>
> java.lang.NoClassDefFoundError:
> org/apache/jena/sparql/engine/main/StageGenerator
>
> Andy
>
> >
> > What weirds me out is that this only happens during debugging.
> >
> > On Wed, Jul 1, 2020 at 9:56 AM Andy Seaborne wrote:
> >>
> >>
> >>
> >> On 30/06/2020 23:11, Martynas Jusevičius wrote:
> >>> Andy,
> >>>
> >>> where do you put JenaSystem.init() in unit tests, for example?
> >>>
> >>> Using 3.16.0-SNAPSHOT, I've changed the test code a little and started
> >>> getting this - though only when I attempt to debug the ConstraintTest
> >>> class:
> >>>
> >>> com.atomgraph.spinrdf.constraints.ConstraintTest Time elapsed: 0.419
> >>> sec <<< ERROR!
> >>> java.lang.NoClassDefFoundError:
> >>> org/apache/jena/sparql/engine/main/StageGenerator
> >>> at org.apache.jena.tdb.sys.InitTDB.start(InitTDB.java:29)
> >>> at org.apache.jena.sys.JenaSystem.lambda$init$2(JenaSystem.java:117)
> >>> at java.util.ArrayList.forEach(ArrayList.java:1257)
> >>> at org.apache.jena.sys.JenaSystem.forEach(JenaSystem.java:192)
> >>> at org.apache.jena.sys.JenaSystem.forEach(JenaSystem.java:169)
> >>> at org.apache.jena.sys.JenaSystem.init(JenaSystem.java:115)
> >>> at
> >>> com.atomgraph.spinrdf.constraints.ConstraintTest.(ConstraintTest.java:51)
> >>>
> >>> The call is in a static initializer:
> >>>
> >>> public class ConstraintTest
> >>> {
> >>>
> >>> static
> >>> {
> >>
> >> You check everything is available with:
> >>
> >> JenaSystem.DEBUG_INIT = true;
> >>
> >>> JenaSystem.init();
> >>> }
> >>>
> >>> Or is this unrelated to the JenaSystem.init()?
> >>
> >>
> >> Unrelated.
> >>
> >> It is as if there is a missing jar.
> >>
> >> Andy
> >>
> >>
> >> Most of the time JenaSystem.init() happens automatically because it is
> >> in a static block of every major entry point class - but Java class
> >> initialization, and the fact that initialization of recursive class is
> >> switched off by off when one class is loading, makes it complicated even
> >> though thread-safe. "static final X = new Object" can be null!
> >>
> >> (RDFLangauges/Lang is particular hard because there is a mutual
> >> dependency that predates the full JenaSystem.init).
> >>
> >>>
> >>> POM:
> >>>
> >>>
> >>> org.apache.jena
> >>> apache-jena-libs
> >>> 3.16.0-SNAPSHOT
> >>> pom
> >>>
> >>>
> >>> On Mon, Jun 29, 2020 at 11:40 PM Martynas Jusevičius
> >>> wrote:
>
> On Mon, Jun 29, 2020 at 6:34 PM Andy Seaborne wrote:
> >
> >
> >
> > On 29/06/2020 14:47, Martynas Jusevičius wrote:
> >> Hi,
> >>
> >> I've got a class that is initialized with Jena's registered languages:
> >
> > And how/when is that called?
> >
> > I presume you don't use Jena initialization mechanism.
> >
> > https://jena.apache.org/documentation/notes/system-initialization
>
> You're right, I've missed that. JenaSystem.init() wasn't being called.
>
> > One thing as a general measure: call "JenaSystem.init()" early in statup
> > before requests come in.
>
> Yes. I was wondering where that could be in a webapp. But then I found
> the FusekiServerEnvironmentInit (ServletContextListener) and
> implemented the same and now it looks like the problem went away.
> https://github.com/apache/jena/blob/master/jena-fuseki2/jena-fuseki-webapp/src/main/java/org/apache/jena/fuseki/webapp/FusekiServerEnvironmentInit.java
Re: ConcurrentModificationException using RDFLanguages.getRegisteredLanguages()
On 01/07/2020 09:58, Martynas Jusevičius wrote:
Thanks.
What jar is missing though? I have apache-jena-libs as a dependency. I
can see it includes TDB and TDB2.
And ARQ - but that disagrees with the error you are seeing:
java.lang.NoClassDefFoundError:
org/apache/jena/sparql/engine/main/StageGenerator
Andy
What weirds me out is that this only happens during debugging.
On Wed, Jul 1, 2020 at 9:56 AM Andy Seaborne wrote:
On 30/06/2020 23:11, Martynas Jusevičius wrote:
Andy,
where do you put JenaSystem.init() in unit tests, for example?
Using 3.16.0-SNAPSHOT, I've changed the test code a little and started
getting this - though only when I attempt to debug the ConstraintTest
class:
com.atomgraph.spinrdf.constraints.ConstraintTest Time elapsed: 0.419
sec <<< ERROR!
java.lang.NoClassDefFoundError:
org/apache/jena/sparql/engine/main/StageGenerator
at org.apache.jena.tdb.sys.InitTDB.start(InitTDB.java:29)
at org.apache.jena.sys.JenaSystem.lambda$init$2(JenaSystem.java:117)
at java.util.ArrayList.forEach(ArrayList.java:1257)
at org.apache.jena.sys.JenaSystem.forEach(JenaSystem.java:192)
at org.apache.jena.sys.JenaSystem.forEach(JenaSystem.java:169)
at org.apache.jena.sys.JenaSystem.init(JenaSystem.java:115)
at
com.atomgraph.spinrdf.constraints.ConstraintTest.(ConstraintTest.java:51)
The call is in a static initializer:
public class ConstraintTest
{
static
{
You check everything is available with:
JenaSystem.DEBUG_INIT = true;
JenaSystem.init();
}
Or is this unrelated to the JenaSystem.init()?
Unrelated.
It is as if there is a missing jar.
Andy
Most of the time JenaSystem.init() happens automatically because it is
in a static block of every major entry point class - but Java class
initialization, and the fact that initialization of recursive class is
switched off by off when one class is loading, makes it complicated even
though thread-safe. "static final X = new Object" can be null!
(RDFLangauges/Lang is particular hard because there is a mutual
dependency that predates the full JenaSystem.init).
POM:
org.apache.jena
apache-jena-libs
3.16.0-SNAPSHOT
pom
On Mon, Jun 29, 2020 at 11:40 PM Martynas Jusevičius
wrote:
On Mon, Jun 29, 2020 at 6:34 PM Andy Seaborne wrote:
On 29/06/2020 14:47, Martynas Jusevičius wrote:
Hi,
I've got a class that is initialized with Jena's registered languages:
And how/when is that called?
I presume you don't use Jena initialization mechanism.
https://jena.apache.org/documentation/notes/system-initialization
You're right, I've missed that. JenaSystem.init() wasn't being called.
One thing as a general measure: call "JenaSystem.init()" early in statup
before requests come in.
Yes. I was wondering where that could be in a webapp. But then I found
the FusekiServerEnvironmentInit (ServletContextListener) and
implemented the same and now it looks like the problem went away.
https://github.com/apache/jena/blob/master/jena-fuseki2/jena-fuseki-webapp/src/main/java/org/apache/jena/fuseki/webapp/FusekiServerEnvironmentInit.java
Re: ConcurrentModificationException using RDFLanguages.getRegisteredLanguages()
Thanks.
What jar is missing though? I have apache-jena-libs as a dependency. I
can see it includes TDB and TDB2.
What weirds me out is that this only happens during debugging.
On Wed, Jul 1, 2020 at 9:56 AM Andy Seaborne wrote:
>
>
>
> On 30/06/2020 23:11, Martynas Jusevičius wrote:
> > Andy,
> >
> > where do you put JenaSystem.init() in unit tests, for example?
> >
> > Using 3.16.0-SNAPSHOT, I've changed the test code a little and started
> > getting this - though only when I attempt to debug the ConstraintTest
> > class:
> >
> > com.atomgraph.spinrdf.constraints.ConstraintTest Time elapsed: 0.419
> > sec <<< ERROR!
> > java.lang.NoClassDefFoundError:
> > org/apache/jena/sparql/engine/main/StageGenerator
> > at org.apache.jena.tdb.sys.InitTDB.start(InitTDB.java:29)
> > at org.apache.jena.sys.JenaSystem.lambda$init$2(JenaSystem.java:117)
> > at java.util.ArrayList.forEach(ArrayList.java:1257)
> > at org.apache.jena.sys.JenaSystem.forEach(JenaSystem.java:192)
> > at org.apache.jena.sys.JenaSystem.forEach(JenaSystem.java:169)
> > at org.apache.jena.sys.JenaSystem.init(JenaSystem.java:115)
> > at
> > com.atomgraph.spinrdf.constraints.ConstraintTest.(ConstraintTest.java:51)
> >
> > The call is in a static initializer:
> >
> > public class ConstraintTest
> > {
> >
> > static
> > {
>
> You check everything is available with:
>
> JenaSystem.DEBUG_INIT = true;
>
> > JenaSystem.init();
> > }
> >
> > Or is this unrelated to the JenaSystem.init()?
>
>
> Unrelated.
>
> It is as if there is a missing jar.
>
> Andy
>
>
> Most of the time JenaSystem.init() happens automatically because it is
> in a static block of every major entry point class - but Java class
> initialization, and the fact that initialization of recursive class is
> switched off by off when one class is loading, makes it complicated even
> though thread-safe. "static final X = new Object" can be null!
>
> (RDFLangauges/Lang is particular hard because there is a mutual
> dependency that predates the full JenaSystem.init).
>
> >
> > POM:
> >
> >
> > org.apache.jena
> > apache-jena-libs
> > 3.16.0-SNAPSHOT
> > pom
> >
> >
> > On Mon, Jun 29, 2020 at 11:40 PM Martynas Jusevičius
> > wrote:
> >>
> >> On Mon, Jun 29, 2020 at 6:34 PM Andy Seaborne wrote:
> >>>
> >>>
> >>>
> >>> On 29/06/2020 14:47, Martynas Jusevičius wrote:
> Hi,
>
> I've got a class that is initialized with Jena's registered languages:
> >>>
> >>> And how/when is that called?
> >>>
> >>> I presume you don't use Jena initialization mechanism.
> >>>
> >>> https://jena.apache.org/documentation/notes/system-initialization
> >>
> >> You're right, I've missed that. JenaSystem.init() wasn't being called.
> >>
> >>> One thing as a general measure: call "JenaSystem.init()" early in statup
> >>> before requests come in.
> >>
> >> Yes. I was wondering where that could be in a webapp. But then I found
> >> the FusekiServerEnvironmentInit (ServletContextListener) and
> >> implemented the same and now it looks like the problem went away.
> >> https://github.com/apache/jena/blob/master/jena-fuseki2/jena-fuseki-webapp/src/main/java/org/apache/jena/fuseki/webapp/FusekiServerEnvironmentInit.java
Re: ConcurrentModificationException using RDFLanguages.getRegisteredLanguages()
On 30/06/2020 23:11, Martynas Jusevičius wrote:
Andy,
where do you put JenaSystem.init() in unit tests, for example?
Using 3.16.0-SNAPSHOT, I've changed the test code a little and started
getting this - though only when I attempt to debug the ConstraintTest
class:
com.atomgraph.spinrdf.constraints.ConstraintTest Time elapsed: 0.419
sec <<< ERROR!
java.lang.NoClassDefFoundError:
org/apache/jena/sparql/engine/main/StageGenerator
at org.apache.jena.tdb.sys.InitTDB.start(InitTDB.java:29)
at org.apache.jena.sys.JenaSystem.lambda$init$2(JenaSystem.java:117)
at java.util.ArrayList.forEach(ArrayList.java:1257)
at org.apache.jena.sys.JenaSystem.forEach(JenaSystem.java:192)
at org.apache.jena.sys.JenaSystem.forEach(JenaSystem.java:169)
at org.apache.jena.sys.JenaSystem.init(JenaSystem.java:115)
at
com.atomgraph.spinrdf.constraints.ConstraintTest.(ConstraintTest.java:51)
The call is in a static initializer:
public class ConstraintTest
{
static
{
You check everything is available with:
JenaSystem.DEBUG_INIT = true;
JenaSystem.init();
}
Or is this unrelated to the JenaSystem.init()?
Unrelated.
It is as if there is a missing jar.
Andy
Most of the time JenaSystem.init() happens automatically because it is
in a static block of every major entry point class - but Java class
initialization, and the fact that initialization of recursive class is
switched off by off when one class is loading, makes it complicated even
though thread-safe. "static final X = new Object" can be null!
(RDFLangauges/Lang is particular hard because there is a mutual
dependency that predates the full JenaSystem.init).
POM:
org.apache.jena
apache-jena-libs
3.16.0-SNAPSHOT
pom
On Mon, Jun 29, 2020 at 11:40 PM Martynas Jusevičius
wrote:
On Mon, Jun 29, 2020 at 6:34 PM Andy Seaborne wrote:
On 29/06/2020 14:47, Martynas Jusevičius wrote:
Hi,
I've got a class that is initialized with Jena's registered languages:
And how/when is that called?
I presume you don't use Jena initialization mechanism.
https://jena.apache.org/documentation/notes/system-initialization
You're right, I've missed that. JenaSystem.init() wasn't being called.
One thing as a general measure: call "JenaSystem.init()" early in statup
before requests come in.
Yes. I was wondering where that could be in a webapp. But then I found
the FusekiServerEnvironmentInit (ServletContextListener) and
implemented the same and now it looks like the problem went away.
https://github.com/apache/jena/blob/master/jena-fuseki2/jena-fuseki-webapp/src/main/java/org/apache/jena/fuseki/webapp/FusekiServerEnvironmentInit.java
Re: ConcurrentModificationException using RDFLanguages.getRegisteredLanguages()
Andy,
where do you put JenaSystem.init() in unit tests, for example?
Using 3.16.0-SNAPSHOT, I've changed the test code a little and started
getting this - though only when I attempt to debug the ConstraintTest
class:
com.atomgraph.spinrdf.constraints.ConstraintTest Time elapsed: 0.419
sec <<< ERROR!
java.lang.NoClassDefFoundError:
org/apache/jena/sparql/engine/main/StageGenerator
at org.apache.jena.tdb.sys.InitTDB.start(InitTDB.java:29)
at org.apache.jena.sys.JenaSystem.lambda$init$2(JenaSystem.java:117)
at java.util.ArrayList.forEach(ArrayList.java:1257)
at org.apache.jena.sys.JenaSystem.forEach(JenaSystem.java:192)
at org.apache.jena.sys.JenaSystem.forEach(JenaSystem.java:169)
at org.apache.jena.sys.JenaSystem.init(JenaSystem.java:115)
at
com.atomgraph.spinrdf.constraints.ConstraintTest.(ConstraintTest.java:51)
The call is in a static initializer:
public class ConstraintTest
{
static
{
JenaSystem.init();
}
Or is this unrelated to the JenaSystem.init()?
POM:
org.apache.jena
apache-jena-libs
3.16.0-SNAPSHOT
pom
On Mon, Jun 29, 2020 at 11:40 PM Martynas Jusevičius
wrote:
>
> On Mon, Jun 29, 2020 at 6:34 PM Andy Seaborne wrote:
> >
> >
> >
> > On 29/06/2020 14:47, Martynas Jusevičius wrote:
> > > Hi,
> > >
> > > I've got a class that is initialized with Jena's registered languages:
> >
> > And how/when is that called?
> >
> > I presume you don't use Jena initialization mechanism.
> >
> > https://jena.apache.org/documentation/notes/system-initialization
>
> You're right, I've missed that. JenaSystem.init() wasn't being called.
>
> > One thing as a general measure: call "JenaSystem.init()" early in statup
> > before requests come in.
>
> Yes. I was wondering where that could be in a webapp. But then I found
> the FusekiServerEnvironmentInit (ServletContextListener) and
> implemented the same and now it looks like the problem went away.
> https://github.com/apache/jena/blob/master/jena-fuseki2/jena-fuseki-webapp/src/main/java/org/apache/jena/fuseki/webapp/FusekiServerEnvironmentInit.java
Re: ConcurrentModificationException using RDFLanguages.getRegisteredLanguages()
On Mon, Jun 29, 2020 at 6:34 PM Andy Seaborne wrote: > > > > On 29/06/2020 14:47, Martynas Jusevičius wrote: > > Hi, > > > > I've got a class that is initialized with Jena's registered languages: > > And how/when is that called? > > I presume you don't use Jena initialization mechanism. > > https://jena.apache.org/documentation/notes/system-initialization You're right, I've missed that. JenaSystem.init() wasn't being called. > One thing as a general measure: call "JenaSystem.init()" early in statup > before requests come in. Yes. I was wondering where that could be in a webapp. But then I found the FusekiServerEnvironmentInit (ServletContextListener) and implemented the same and now it looks like the problem went away. https://github.com/apache/jena/blob/master/jena-fuseki2/jena-fuseki-webapp/src/main/java/org/apache/jena/fuseki/webapp/FusekiServerEnvironmentInit.java
Re: ConcurrentModificationException using RDFLanguages.getRegisteredLanguages()
On 29/06/2020 14:47, Martynas Jusevičius wrote:
Hi,
I've got a class that is initialized with Jena's registered languages:
And how/when is that called?
I presume you don't use Jena initialization mechanism.
https://jena.apache.org/documentation/notes/system-initialization
public MediaTypes()
{
this(RDFLanguages.getRegisteredLanguages(), UTF8_PARAM);
}
protected MediaTypes(Collection registered, Map parameters)
{
...
Iterator langIt = registered.iterator();
while (langIt.hasNext())
{
Lang lang = langIt.next();
...
After the upgrade to 3.16.0-SNAPSHOT, I am getting a
ConcurrentModificationException on the langIt.next() (worked without
problems with 3.0.1).
Where's the concurrency coming from?
Always? Often? Sometimes?
I've been able to debug that the MediaTypes() constructor is being
called while Jena's languages are not done initializing yet.
The breakpoint at line 256 is from within RDFLanguages.register(Lang
lang); at line 71 is the MediaTypes() constructor.
Does your code initialize Jena explicitly or leave it to requests? That
would be the concurrency?
One thing as a general measure: call "JenaSystem.init()" early in statup
before requests come in.
...
Breakpoint hit at line 256 in class org.apache.jena.riot.RDFLanguages
by thread http-nio-8080-exec-290.
Breakpoint hit at line 256 in class org.apache.jena.riot.RDFLanguages
by thread http-nio-8080-exec-290.
Breakpoint hit at line 71 in class com.atomgraph.core.MediaTypes by
thread http-nio-8080-exec-290.
Breakpoint hit at line 256 in class org.apache.jena.riot.RDFLanguages
by thread http-nio-8080-exec-290.
Breakpoint hit at line 256 in class org.apache.jena.riot.RDFLanguages
by thread http-nio-8080-exec-290.
...
I cannot get the caller info with NetBeans, but I'm quite sure these
are Jena's internal RDFLanguages.register() calls as I've removed all
calls from our code for now.
This is more of a general static initialization problem I suppose, but
how would you go about addressing it? How does one get all the
languages from RDFLanguages.getRegisteredLanguages()? There's no hook
that would notify completed registration AFAIK.
Thanks.
Martynas
Re: ConcurrentModificationException for Jena 3.5.0 SELECT query
On 05/01/18 08:56, Florian Kleedorfer wrote: Am 2018-01-04 22:56, schrieb Andy Seaborne: On 04/01/18 20:59, Florian Kleedorfer wrote: Am 2018-01-03 20:42, schrieb Andy Seaborne: Hi Florian, I can't see what's happening just by reading the code but ResultSet resultSet = queryExecution.execSelect() does not detach the results from the queried dataset (the RDFNodes refer back to the queried dataset). (BTW What sort of dataset is "conversationDataset"?) the conversationDataset is created with DatasetFactory.createGeneral, too You could try: ResultSet resultSet = queryExecution.execSelect(); resutlSet = ResultSetFactory.copyResults(resultSet); Thanks for that hint - did not know that one! However, I'm not sure that is the issue here - the exception is thrown when resultSet.hasNext() is called for the *first* time. It's an ORDER BY so a lot of work happen on first "hasNext". Another good thing to try is executing the query without the process and just printout the results. But I thought, as the exception happens before any of our result processing, the only possible causes are the data, the query, and the dataset type. Isn't that correct? conversationDataset This can have only weak transaction isolation (using DatasetFactory.createTxnMem is full ACID, createGeneral is not). "general" links to graphs so it is sharing. For example, code can ignore transactions and another thread update just because it feels like it. Even DatasetFactory.create is safer (it copies data in). I'll try with different dataset types and report. And "ResultSetFactory.copyResults"? if it is external interference this reduces the window of vulnerability, though not eliminated it. (The first data doesn't return any results for me anyway) That's intended - it's a negative example from our unit tests, the query should not return anything. Then for me, the queries are fine and it looks like an external effect. Andy
Re: ConcurrentModificationException for Jena 3.5.0 SELECT query
Am 2018-01-04 22:56, schrieb Andy Seaborne: On 04/01/18 20:59, Florian Kleedorfer wrote: Am 2018-01-03 20:42, schrieb Andy Seaborne: Hi Florian, I can't see what's happening just by reading the code but ResultSet resultSet = queryExecution.execSelect() does not detach the results from the queried dataset (the RDFNodes refer back to the queried dataset). (BTW What sort of dataset is "conversationDataset"?) the conversationDataset is created with DatasetFactory.createGeneral, too You could try: ResultSet resultSet = queryExecution.execSelect(); resutlSet = ResultSetFactory.copyResults(resultSet); Thanks for that hint - did not know that one! However, I'm not sure that is the issue here - the exception is thrown when resultSet.hasNext() is called for the *first* time. It's an ORDER BY so a lot of work happen on first "hasNext". Another good thing to try is executing the query without the process and just printout the results. But I thought, as the exception happens before any of our result processing, the only possible causes are the data, the query, and the dataset type. Isn't that correct? I'll try with different dataset types and report. (The first data doesn't return any results for me anyway) That's intended - it's a negative example from our unit tests, the query should not return anything.
Re: ConcurrentModificationException for Jena 3.5.0 SELECT query
On 04/01/18 20:59, Florian Kleedorfer wrote: Am 2018-01-03 20:42, schrieb Andy Seaborne: Hi Florian, I can't see what's happening just by reading the code but ResultSet resultSet = queryExecution.execSelect() does not detach the results from the queried dataset (the RDFNodes refer back to the queried dataset). (BTW What sort of dataset is "conversationDataset"?) the conversationDataset is created with DatasetFactory.createGeneral, too You could try: ResultSet resultSet = queryExecution.execSelect(); resutlSet = ResultSetFactory.copyResults(resultSet); Thanks for that hint - did not know that one! However, I'm not sure that is the issue here - the exception is thrown when resultSet.hasNext() is called for the *first* time. It's an ORDER BY so a lot of work happen on first "hasNext". Another good thing to try is executing the query without the process and just printout the results. (The first data doesn't return any results for me anyway) Andy to ensure the results loop has a safe copy (it isn't very expensive to do this - an ArrayList is created and but the raw data of the query processing does not need to be copied - they are immutable values). Unrelated: A good choice of in-memory dataset for this kind of processing is: Dataset result = DatasetFactory.createTxnMem(); because the code overwrites at L63. Thanks! I'm never too sure how to decide for any of them because I don't know exactly what the trade-off is. Best Florian
Re: ConcurrentModificationException for Jena 3.5.0 SELECT query
Am 2018-01-03 20:42, schrieb Andy Seaborne: Hi Florian, I can't see what's happening just by reading the code but ResultSet resultSet = queryExecution.execSelect() does not detach the results from the queried dataset (the RDFNodes refer back to the queried dataset). (BTW What sort of dataset is "conversationDataset"?) the conversationDataset is created with DatasetFactory.createGeneral, too You could try: ResultSet resultSet = queryExecution.execSelect(); resutlSet = ResultSetFactory.copyResults(resultSet); Thanks for that hint - did not know that one! However, I'm not sure that is the issue here - the exception is thrown when resultSet.hasNext() is called for the *first* time. to ensure the results loop has a safe copy (it isn't very expensive to do this - an ArrayList is created and but the raw data of the query processing does not need to be copied - they are immutable values). Unrelated: A good choice of in-memory dataset for this kind of processing is: Dataset result = DatasetFactory.createTxnMem(); because the code overwrites at L63. Thanks! I'm never too sure how to decide for any of them because I don't know exactly what the trade-off is. Best Florian
Re: ConcurrentModificationException for Jena 3.5.0 SELECT query
> Unrelated:
> A good choice of in-memory dataset for this kind of processing is:
>
> Dataset result = DatasetFactory.createTxnMem();
>
> because the code overwrites at L63.
Andy, I'm not sure if what follows is what you meant anyway, but just to be
clear:
TIM (which is what one gets from DatasetFactory.createTxnMem()), on
Dataset::addNamedModel would copy the triples from the given model into the
identified named model adding them to whatever is there. If overwriting is what
is desired, Dataset::replaceNamedModel would do that, but unfortunately, it
won't be any faster, because DatasetImpl::replaceNamedModel just does
DatasetGraph::removeGraph and then DatasetGraph::addGraph on the underlying
DatasetGraph. TIM has copy-on-add semantics for graphs (not for quads).
Wouldn't createGeneral actually be better (faster) here, because it just takes
the reference and doesn't copy the triples?
---
Here's some more unrelated advice for Florian :grin:
You show
> RDFNode agreementNode = solution.get("acc");
...
> RDFNode s = solution.get("s");
> RDFNode p = solution.get("p");
> RDFNode o = solution.get("o");
and you store a triple of s,p,o in a named model named by acc, which seems to
imply that your SELECT query is just building quads. In that case it might be
worth taking advantage of Jena's extensions (available in Fuseki) to support
CONSTRUCT building quads:
https://jena.apache.org/documentation/query/construct-quad.html
Then the results you get back could just be used directly as a dataset. I don't
know what your SPARQL queries look like or how complicated it would be to
rewrite them for this style or whether you are comfortable using extensions to
SPARQL, but it would certainly simplify the code you show in your gist.
ajs6f
> On Jan 3, 2018, at 2:42 PM, Andy Seaborne wrote:
>
> Hi Florian,
>
> I can't see what's happening just by reading the code but
>
> ResultSet resultSet = queryExecution.execSelect()
>
> does not detach the results from the queried dataset (the RDFNodes refer back
> to the queried dataset). (BTW What sort of dataset is "conversationDataset"?)
>
> You could try:
>
> ResultSet resultSet = queryExecution.execSelect();
> resutlSet = ResultSetFactory.copyResults(resultSet);
>
> to ensure the results loop has a safe copy (it isn't very expensive to do
> this - an ArrayList is created and but the raw data of the query processing
> does not need to be copied - they are immutable values).
>
>
> Unrelated:
> A good choice of in-memory dataset for this kind of processing is:
>
> Dataset result = DatasetFactory.createTxnMem();
>
> because the code overwrites at L63.
>
>Andy
>
>
> On 03/01/18 16:23, Florian Kleedorfer wrote:
>> Hi,
>> We encounter an unexpected ConcurrentModificationException with a SELECT
>> query
>> using Jena 3.5.0.
>> We also found a reformulation of the query so the Exception is not thrown.
>> All data is in this gist:
>> https://gist.github.com/fkleedorfer/4c4da3ccc21132490b4990f960a8ca2f
>> * AgreementFunction.java: The code executing the query (for context)
>> * query-throwing-exception.sq: The query throwing the exception when run
>> * exception.txt: the exception
>> * data-causing-exception.trig: the dataset on which the query fails
>> * data-not-causing-exception.trig: an almost identical dataset on which the
>> query does not fail (diff: lines 66-70 are only present in this one)
>> * query-with-workaround.sq: the 'fixed' query that, according to our unit
>> tests, does
>> the same but does not fail.
>> The problem seems to occur when the variable ?clauseContent is bound in the
>> BGP in
>> query-throwing-exception.sq:12 but there is no RDF graph with name
>> ?clauseContent
>> (query-throwing-exception.sq:14). Such a graph is missing in
>> data-causing-exception.trig
>> but is present in data-not-causing-exception.trig. The workaround seems the
>> change the
>> order in which bindings are checked.
>> As we seem to have an acceptable workaround, this is not urgent, but I hope
>> it helps you!
>> Also: Thanks for a great great piece of software!
>> Cheers!
>> Florian
Re: ConcurrentModificationException for Jena 3.5.0 SELECT query
Hi Florian, I can't see what's happening just by reading the code but ResultSet resultSet = queryExecution.execSelect() does not detach the results from the queried dataset (the RDFNodes refer back to the queried dataset). (BTW What sort of dataset is "conversationDataset"?) You could try: ResultSet resultSet = queryExecution.execSelect(); resutlSet = ResultSetFactory.copyResults(resultSet); to ensure the results loop has a safe copy (it isn't very expensive to do this - an ArrayList is created and but the raw data of the query processing does not need to be copied - they are immutable values). Unrelated: A good choice of in-memory dataset for this kind of processing is: Dataset result = DatasetFactory.createTxnMem(); because the code overwrites at L63. Andy On 03/01/18 16:23, Florian Kleedorfer wrote: Hi, We encounter an unexpected ConcurrentModificationException with a SELECT query using Jena 3.5.0. We also found a reformulation of the query so the Exception is not thrown. All data is in this gist: https://gist.github.com/fkleedorfer/4c4da3ccc21132490b4990f960a8ca2f * AgreementFunction.java: The code executing the query (for context) * query-throwing-exception.sq: The query throwing the exception when run * exception.txt: the exception * data-causing-exception.trig: the dataset on which the query fails * data-not-causing-exception.trig: an almost identical dataset on which the query does not fail (diff: lines 66-70 are only present in this one) * query-with-workaround.sq: the 'fixed' query that, according to our unit tests, does the same but does not fail. The problem seems to occur when the variable ?clauseContent is bound in the BGP in query-throwing-exception.sq:12 but there is no RDF graph with name ?clauseContent (query-throwing-exception.sq:14). Such a graph is missing in data-causing-exception.trig but is present in data-not-causing-exception.trig. The workaround seems the change the order in which bindings are checked. As we seem to have an acceptable workaround, this is not urgent, but I hope it helps you! Also: Thanks for a great great piece of software! Cheers! Florian
Re: ConcurrentModificationException
On 15/09/16 13:16, Laurent Rucquoy wrote:
Hi Andy,
I've moved the model.close() call inside the transaction (sorry for
this careless mistake) and it works now !
Maybe, maybe not!
While investigating I couldn't provoke the error either way round - it
seems to be related to the update performed and I did not manage to
guess the right kind. The stack trace does not suggest it is
model.close related.
What is the SPARQL Update?
Andy
Thank you very much for your help.
Laurent
On 14 September 2016 at 18:28, Andy Seaborne wrote:
Hi Laurent,
On 14/09/16 15:16, Laurent Rucquoy wrote:
Hi Andy,
Thank you for your help.
I have tested the following code according to your suggestions (get the
model inside the transaction and remove the use of locks):
dataset.begin(ReadWrite.WRITE);
Model model = dataset.getNamedModel("http://my-model-name";);
try {
UpdateAction.parseExecute(sparql, model);
What is the update?
if(writeMode) {
dataset.commit();
}
} finally {
model.close();
You are using the model after the commit
dataset.end();
}
Andy
When multiple updates are made on our TDB-backed dataset, the java.util.
ConcurrentModificationException is still thrown, leaving the dataset in
an
inaccessible state.
Here is the stacktrace part:
Caused by: java.util.ConcurrentModificationException: Iterator: started
at
5, now 8
at
org.apache.jena.tdb.sys.DatasetControlMRSW.policyError(Datas
etControlMRSW.java:157)
at
org.apache.jena.tdb.sys.DatasetControlMRSW.access$000(Datase
tControlMRSW.java:32)
at
org.apache.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotC
oncurrent.checkCourrentModification(DatasetControlMRSW.java:110)
at
org.apache.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotC
oncurrent.hasNext(DatasetControlMRSW.java:118)
at org.apache.jena.atlas.iterator.Iter$2.hasNext(Iter.java:265)
at org.apache.jena.atlas.iterator.Iter.hasNext(Iter.java:870)
at org.apache.jena.atlas.iterator.Iter$1.hasNext(Iter.java:192)
at org.apache.jena.atlas.iterator.Iter.hasNext(Iter.java:870)
at
org.apache.jena.atlas.iterator.RepeatApplyIterator.hasNext(
RepeatApplyIterator.java:58)
at
org.apache.jena.tdb.solver.SolverLib$IterAbortable.hasNext(
SolverLib.java:195)
at org.apache.jena.atlas.iterator.Iter$2.hasNext(Iter.java:265)
at
org.apache.jena.sparql.engine.iterator.QueryIterPlainWrapper
.hasNextBinding(QueryIterPlainWrapper.java:53)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.has
Next(QueryIteratorBase.java:111)
at
org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.
makeNextStage(QueryIterRepeatApply.java:101)
at
org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.
hasNextBinding(QueryIterRepeatApply.java:65)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.has
Next(QueryIteratorBase.java:111)
at org.apache.jena.atlas.iterator.Iter$2.hasNext(Iter.java:265)
at
org.apache.jena.atlas.iterator.RepeatApplyIterator.hasNext(
RepeatApplyIterator.java:45)
at
org.apache.jena.tdb.solver.SolverLib$IterAbortable.hasNext(
SolverLib.java:195)
at org.apache.jena.atlas.iterator.Iter$2.hasNext(Iter.java:265)
at
org.apache.jena.sparql.engine.iterator.QueryIterPlainWrapper
.hasNextBinding(QueryIterPlainWrapper.java:53)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.has
Next(QueryIteratorBase.java:111)
at org.apache.jena.atlas.iterator.Iter$2.hasNext(Iter.java:265)
at
org.apache.jena.atlas.iterator.RepeatApplyIterator.hasNext(
RepeatApplyIterator.java:45)
at
org.apache.jena.tdb.solver.SolverLib$IterAbortable.hasNext(
SolverLib.java:195)
at org.apache.jena.atlas.iterator.Iter$2.hasNext(Iter.java:265)
at
org.apache.jena.sparql.engine.iterator.QueryIterPlainWrapper
.hasNextBinding(QueryIterPlainWrapper.java:53)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.has
Next(QueryIteratorBase.java:111)
at
org.apache.jena.sparql.engine.iterator.QueryIterConcat.hasNe
xtBinding(QueryIterConcat.java:82)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.has
Next(QueryIteratorBase.java:111)
at
org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.
hasNextBinding(QueryIterRepeatApply.java:74)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.has
Next(QueryIteratorBase.java:111)
at
org.apache.jena.sparql.engine.iterator.QueryIterConvert.hasN
extBinding(QueryIterConvert.java:58)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.has
Next(QueryIteratorBase.java:111)
at
org.apache.jena.sparql.engine.iterator.QueryIterDistinct.get
InputNextUnseen(QueryIterDistinct.java:104)
at
org.apache.jena.sparql.engine.iterator.QueryIterDistinct.has
NextBinding(QueryIterDistinct.java:70)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.has
Next(QueryIteratorBase.java:111)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorWrapper.
hasNextBinding(QueryIteratorWrapper.java:39)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.has
Next(QueryIteratorBase.java:111)
at
org.apache.jena.
Re: ConcurrentModificationException
Hi Andy,
I've moved the model.close() call inside the transaction (sorry for
this careless mistake) and it works now !
Thank you very much for your help.
Laurent
On 14 September 2016 at 18:28, Andy Seaborne wrote:
> Hi Laurent,
>
> On 14/09/16 15:16, Laurent Rucquoy wrote:
>
>> Hi Andy,
>>
>> Thank you for your help.
>>
>> I have tested the following code according to your suggestions (get the
>> model inside the transaction and remove the use of locks):
>>
>> dataset.begin(ReadWrite.WRITE);
>>
>>> Model model = dataset.getNamedModel("http://my-model-name";);
>>> try {
>>> UpdateAction.parseExecute(sparql, model);
>>>
>>
> What is the update?
>
> if(writeMode) {
>>> dataset.commit();
>>> }
>>> } finally {
>>>
>>> model.close();
>>>
>>
> You are using the model after the commit
>
> dataset.end();
>>> }
>>>
>>
>>
> Andy
>
>
>> When multiple updates are made on our TDB-backed dataset, the java.util.
>> ConcurrentModificationException is still thrown, leaving the dataset in
>> an
>>
>> inaccessible state.
>> Here is the stacktrace part:
>>
>> Caused by: java.util.ConcurrentModificationException: Iterator: started
>> at
>>
>>> 5, now 8
>>> at
>>> org.apache.jena.tdb.sys.DatasetControlMRSW.policyError(Datas
>>> etControlMRSW.java:157)
>>> at
>>> org.apache.jena.tdb.sys.DatasetControlMRSW.access$000(Datase
>>> tControlMRSW.java:32)
>>> at
>>> org.apache.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotC
>>> oncurrent.checkCourrentModification(DatasetControlMRSW.java:110)
>>> at
>>> org.apache.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotC
>>> oncurrent.hasNext(DatasetControlMRSW.java:118)
>>> at org.apache.jena.atlas.iterator.Iter$2.hasNext(Iter.java:265)
>>> at org.apache.jena.atlas.iterator.Iter.hasNext(Iter.java:870)
>>> at org.apache.jena.atlas.iterator.Iter$1.hasNext(Iter.java:192)
>>> at org.apache.jena.atlas.iterator.Iter.hasNext(Iter.java:870)
>>> at
>>> org.apache.jena.atlas.iterator.RepeatApplyIterator.hasNext(
>>> RepeatApplyIterator.java:58)
>>> at
>>> org.apache.jena.tdb.solver.SolverLib$IterAbortable.hasNext(
>>> SolverLib.java:195)
>>> at org.apache.jena.atlas.iterator.Iter$2.hasNext(Iter.java:265)
>>> at
>>> org.apache.jena.sparql.engine.iterator.QueryIterPlainWrapper
>>> .hasNextBinding(QueryIterPlainWrapper.java:53)
>>> at
>>> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.has
>>> Next(QueryIteratorBase.java:111)
>>> at
>>> org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.
>>> makeNextStage(QueryIterRepeatApply.java:101)
>>> at
>>> org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.
>>> hasNextBinding(QueryIterRepeatApply.java:65)
>>> at
>>> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.has
>>> Next(QueryIteratorBase.java:111)
>>> at org.apache.jena.atlas.iterator.Iter$2.hasNext(Iter.java:265)
>>> at
>>> org.apache.jena.atlas.iterator.RepeatApplyIterator.hasNext(
>>> RepeatApplyIterator.java:45)
>>> at
>>> org.apache.jena.tdb.solver.SolverLib$IterAbortable.hasNext(
>>> SolverLib.java:195)
>>> at org.apache.jena.atlas.iterator.Iter$2.hasNext(Iter.java:265)
>>> at
>>> org.apache.jena.sparql.engine.iterator.QueryIterPlainWrapper
>>> .hasNextBinding(QueryIterPlainWrapper.java:53)
>>> at
>>> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.has
>>> Next(QueryIteratorBase.java:111)
>>> at org.apache.jena.atlas.iterator.Iter$2.hasNext(Iter.java:265)
>>> at
>>> org.apache.jena.atlas.iterator.RepeatApplyIterator.hasNext(
>>> RepeatApplyIterator.java:45)
>>> at
>>> org.apache.jena.tdb.solver.SolverLib$IterAbortable.hasNext(
>>> SolverLib.java:195)
>>> at org.apache.jena.atlas.iterator.Iter$2.hasNext(Iter.java:265)
>>> at
>>> org.apache.jena.sparql.engine.iterator.QueryIterPlainWrapper
>>> .hasNextBinding(QueryIterPlainWrapper.java:53)
>>> at
>>> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.has
>>> Next(QueryIteratorBase.java:111)
>>> at
>>> org.apache.jena.sparql.engine.iterator.QueryIterConcat.hasNe
>>> xtBinding(QueryIterConcat.java:82)
>>> at
>>> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.has
>>> Next(QueryIteratorBase.java:111)
>>> at
>>> org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.
>>> hasNextBinding(QueryIterRepeatApply.java:74)
>>> at
>>> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.has
>>> Next(QueryIteratorBase.java:111)
>>> at
>>> org.apache.jena.sparql.engine.iterator.QueryIterConvert.hasN
>>> extBinding(QueryIterConvert.java:58)
>>> at
>>> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.has
>>> Next(QueryIteratorBase.java:111)
>>> at
>>> org.apache.jena.sparql.engine.iterator.QueryIterDistinct.get
>>> InputNextUnseen(QueryIterDistinct.java:104)
>>> at
>>> org.apache.jena.sparql.engine.iterator.QueryIterDistinct.has
>>> NextBinding(QueryIterDistinct.java:70)
>>> at
>>> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.has
>>> Next(QueryIteratorBase.java:111)
>>> at
>>> org.apache.jena.sparql.engine.iterator.QueryIteratorWrapper.
>>> h
Re: ConcurrentModificationException
Hi Laurent,
On 14/09/16 15:16, Laurent Rucquoy wrote:
Hi Andy,
Thank you for your help.
I have tested the following code according to your suggestions (get the
model inside the transaction and remove the use of locks):
dataset.begin(ReadWrite.WRITE);
Model model = dataset.getNamedModel("http://my-model-name";);
try {
UpdateAction.parseExecute(sparql, model);
What is the update?
if(writeMode) {
dataset.commit();
}
} finally {
model.close();
You are using the model after the commit
dataset.end();
}
Andy
When multiple updates are made on our TDB-backed dataset, the java.util.
ConcurrentModificationException is still thrown, leaving the dataset in an
inaccessible state.
Here is the stacktrace part:
Caused by: java.util.ConcurrentModificationException: Iterator: started at
5, now 8
at
org.apache.jena.tdb.sys.DatasetControlMRSW.policyError(DatasetControlMRSW.java:157)
at
org.apache.jena.tdb.sys.DatasetControlMRSW.access$000(DatasetControlMRSW.java:32)
at
org.apache.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.checkCourrentModification(DatasetControlMRSW.java:110)
at
org.apache.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.hasNext(DatasetControlMRSW.java:118)
at org.apache.jena.atlas.iterator.Iter$2.hasNext(Iter.java:265)
at org.apache.jena.atlas.iterator.Iter.hasNext(Iter.java:870)
at org.apache.jena.atlas.iterator.Iter$1.hasNext(Iter.java:192)
at org.apache.jena.atlas.iterator.Iter.hasNext(Iter.java:870)
at
org.apache.jena.atlas.iterator.RepeatApplyIterator.hasNext(RepeatApplyIterator.java:58)
at
org.apache.jena.tdb.solver.SolverLib$IterAbortable.hasNext(SolverLib.java:195)
at org.apache.jena.atlas.iterator.Iter$2.hasNext(Iter.java:265)
at
org.apache.jena.sparql.engine.iterator.QueryIterPlainWrapper.hasNextBinding(QueryIterPlainWrapper.java:53)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:111)
at
org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.makeNextStage(QueryIterRepeatApply.java:101)
at
org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBinding(QueryIterRepeatApply.java:65)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:111)
at org.apache.jena.atlas.iterator.Iter$2.hasNext(Iter.java:265)
at
org.apache.jena.atlas.iterator.RepeatApplyIterator.hasNext(RepeatApplyIterator.java:45)
at
org.apache.jena.tdb.solver.SolverLib$IterAbortable.hasNext(SolverLib.java:195)
at org.apache.jena.atlas.iterator.Iter$2.hasNext(Iter.java:265)
at
org.apache.jena.sparql.engine.iterator.QueryIterPlainWrapper.hasNextBinding(QueryIterPlainWrapper.java:53)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:111)
at org.apache.jena.atlas.iterator.Iter$2.hasNext(Iter.java:265)
at
org.apache.jena.atlas.iterator.RepeatApplyIterator.hasNext(RepeatApplyIterator.java:45)
at
org.apache.jena.tdb.solver.SolverLib$IterAbortable.hasNext(SolverLib.java:195)
at org.apache.jena.atlas.iterator.Iter$2.hasNext(Iter.java:265)
at
org.apache.jena.sparql.engine.iterator.QueryIterPlainWrapper.hasNextBinding(QueryIterPlainWrapper.java:53)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:111)
at
org.apache.jena.sparql.engine.iterator.QueryIterConcat.hasNextBinding(QueryIterConcat.java:82)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:111)
at
org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBinding(QueryIterRepeatApply.java:74)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:111)
at
org.apache.jena.sparql.engine.iterator.QueryIterConvert.hasNextBinding(QueryIterConvert.java:58)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:111)
at
org.apache.jena.sparql.engine.iterator.QueryIterDistinct.getInputNextUnseen(QueryIterDistinct.java:104)
at
org.apache.jena.sparql.engine.iterator.QueryIterDistinct.hasNextBinding(QueryIterDistinct.java:70)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:111)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNextBinding(QueryIteratorWrapper.java:39)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:111)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNextBinding(QueryIteratorWrapper.java:39)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:111)
at
org.apache.jena.sparql.engine.ResultSetStream.hasNext(ResultSetStream.java:74)
at
org.apache.jena.sparql.engine.ResultSetCheckCondition.hasNext(ResultSetCheckCondition.java:59)
Regards,
Laurent
On 14 September 2016 at 11:36, Andy Seaborne wrote:
Hi Laurant,
Try getting the model inside transaction, not passing it across
transaction boundaries.
dataset.begin(ReadWrite.WRITE);
try {
Model model
Re: ConcurrentModificationException
Hi Andy,
Thank you for your help.
I have tested the following code according to your suggestions (get the
model inside the transaction and remove the use of locks):
dataset.begin(ReadWrite.WRITE);
> Model model = dataset.getNamedModel("http://my-model-name";);
> try {
> UpdateAction.parseExecute(sparql, model);
> if(writeMode) {
> dataset.commit();
> }
> } finally {
>
> model.close();
> dataset.end();
> }
When multiple updates are made on our TDB-backed dataset, the java.util.
ConcurrentModificationException is still thrown, leaving the dataset in an
inaccessible state.
Here is the stacktrace part:
Caused by: java.util.ConcurrentModificationException: Iterator: started at
> 5, now 8
> at
> org.apache.jena.tdb.sys.DatasetControlMRSW.policyError(DatasetControlMRSW.java:157)
> at
> org.apache.jena.tdb.sys.DatasetControlMRSW.access$000(DatasetControlMRSW.java:32)
> at
> org.apache.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.checkCourrentModification(DatasetControlMRSW.java:110)
> at
> org.apache.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.hasNext(DatasetControlMRSW.java:118)
> at org.apache.jena.atlas.iterator.Iter$2.hasNext(Iter.java:265)
> at org.apache.jena.atlas.iterator.Iter.hasNext(Iter.java:870)
> at org.apache.jena.atlas.iterator.Iter$1.hasNext(Iter.java:192)
> at org.apache.jena.atlas.iterator.Iter.hasNext(Iter.java:870)
> at
> org.apache.jena.atlas.iterator.RepeatApplyIterator.hasNext(RepeatApplyIterator.java:58)
> at
> org.apache.jena.tdb.solver.SolverLib$IterAbortable.hasNext(SolverLib.java:195)
> at org.apache.jena.atlas.iterator.Iter$2.hasNext(Iter.java:265)
> at
> org.apache.jena.sparql.engine.iterator.QueryIterPlainWrapper.hasNextBinding(QueryIterPlainWrapper.java:53)
> at
> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:111)
> at
> org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.makeNextStage(QueryIterRepeatApply.java:101)
> at
> org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBinding(QueryIterRepeatApply.java:65)
> at
> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:111)
> at org.apache.jena.atlas.iterator.Iter$2.hasNext(Iter.java:265)
> at
> org.apache.jena.atlas.iterator.RepeatApplyIterator.hasNext(RepeatApplyIterator.java:45)
> at
> org.apache.jena.tdb.solver.SolverLib$IterAbortable.hasNext(SolverLib.java:195)
> at org.apache.jena.atlas.iterator.Iter$2.hasNext(Iter.java:265)
> at
> org.apache.jena.sparql.engine.iterator.QueryIterPlainWrapper.hasNextBinding(QueryIterPlainWrapper.java:53)
> at
> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:111)
> at org.apache.jena.atlas.iterator.Iter$2.hasNext(Iter.java:265)
> at
> org.apache.jena.atlas.iterator.RepeatApplyIterator.hasNext(RepeatApplyIterator.java:45)
> at
> org.apache.jena.tdb.solver.SolverLib$IterAbortable.hasNext(SolverLib.java:195)
> at org.apache.jena.atlas.iterator.Iter$2.hasNext(Iter.java:265)
> at
> org.apache.jena.sparql.engine.iterator.QueryIterPlainWrapper.hasNextBinding(QueryIterPlainWrapper.java:53)
> at
> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:111)
> at
> org.apache.jena.sparql.engine.iterator.QueryIterConcat.hasNextBinding(QueryIterConcat.java:82)
> at
> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:111)
> at
> org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBinding(QueryIterRepeatApply.java:74)
> at
> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:111)
> at
> org.apache.jena.sparql.engine.iterator.QueryIterConvert.hasNextBinding(QueryIterConvert.java:58)
> at
> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:111)
> at
> org.apache.jena.sparql.engine.iterator.QueryIterDistinct.getInputNextUnseen(QueryIterDistinct.java:104)
> at
> org.apache.jena.sparql.engine.iterator.QueryIterDistinct.hasNextBinding(QueryIterDistinct.java:70)
> at
> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:111)
> at
> org.apache.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNextBinding(QueryIteratorWrapper.java:39)
> at
> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:111)
> at
> org.apache.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNextBinding(QueryIteratorWrapper.java:39)
> at
> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:111)
> at
> org.apache.jena.sparql.engine.ResultSetStream.hasNext(ResultSetStream.java:74)
> at
> org.apache.jena.sparql.engine.ResultSetCheckCondition.hasNext(ResultSetCheckCondition.java:59)
Regards,
Laurent
On 14 September 2016 at 11:36, Andy Seaborne wrote:
> Hi Laurant,
>
> Try getting the model inside transaction, not passing it across
> transaction boundaries.
>
> dataset.begi
Re: ConcurrentModificationException
Hi Laurant,
Try getting the model inside transaction, not passing it across
transaction boundaries.
dataset.begin(ReadWrite.WRITE);
try {
Model model = dataset.get...
...
dataset.commit() ;
} ...
In 3.1.0, the model is (sort of) connected to the transaction in which
it is created. This is fixed in the next release but style-wise,
because model are just views of the database, they are related to
transactions.
No need to close the model but it's harmless to do so.
You don't need the locking as well as transactions.
Andy
On 14/09/16 08:59, Laurent Rucquoy wrote:
Hello,
We use a Jena TDB-backed dataset (release 3.1.0) accessed through a single
JVM multi-threaded application running generally on a Microsoft Windows
server.
The read and write accesses are made using transaction and read/write locks.
Here is the SPARQL update code we use:
dataset.begin(ReadWrite.WRITE);
model.enterCriticalSection(Lock.WRITE);
try {
UpdateAction.parseExecute(sparql, model);
if(writeMode) {
dataset.commit();
}
} finally {
model.leaveCriticalSection();
model.close();
dataset.end();
}
Note that our SPARQL query code implements also read transactions and locks.
When multiple updates are made on our TDB-backed dataset, a
java.util.ConcurrentModificationException is sometimes thrown, leaving the
dataset in an inaccessible state.
Here is the stacktrace part:
...
Caused by: java.util.ConcurrentModificationException: Reader = 1, Writer =
1
at
org.apache.jena.tdb.sys.DatasetControlMRSW.policyError(DatasetControlMRSW.java:157)
at
org.apache.jena.tdb.sys.DatasetControlMRSW.policyError(DatasetControlMRSW.java:152)
at
org.apache.jena.tdb.sys.DatasetControlMRSW.checkConcurrency(DatasetControlMRSW.java:79)
at
org.apache.jena.tdb.sys.DatasetControlMRSW.startUpdate(DatasetControlMRSW.java:60)
at
org.apache.jena.tdb.store.nodetupletable.NodeTupleTableConcrete.startWrite(NodeTupleTableConcrete.java:65)
at
org.apache.jena.tdb.store.nodetupletable.NodeTupleTableConcrete.sync(NodeTupleTableConcrete.java:249)
How can we avoid such a situation ?
Can we safely do without read/write locks when we use transactions in a
single JVM multi-threaded application ?
Thank you in advance for your help.
Sincerely,
Laurent
Re: ConcurrentModificationException responding to View Request's
On 13/08/14 18:21, Devlin Junker wrote: Hi, Found that the problem was due to to trying to add a submodel and OWL:imports statement during the same transaction. I had to finish and commit the transaction where I add the submodel first, then start another transaction that would read the Class Restrictions. Sometimes I just need to explain the problem in order to better solve it, sorry about that. :x Devlin :-) Java's ConcurrentModificationException is a bit misnamed. It's not threading concurrency, it's change operations while some iterator is still being iterated over. Some update to the underlying data happened between the iterator being created and iteration that went CME. TDB happens to have explicit checking but it can happen anywhere. I'm not clear if this is general bug in Jena. I didn't manage to rebuild your code fragment but just looking at it I don't see any suspicious iterator usage. Andy
Re: ConcurrentModificationException responding to View Request's
Hi, Found that the problem was due to to trying to add a submodel and OWL:imports statement during the same transaction. I had to finish and commit the transaction where I add the submodel first, then start another transaction that would read the Class Restrictions. Sometimes I just need to explain the problem in order to better solve it, sorry about that. :x Devlin On Wed, Aug 13, 2014 at 9:22 AM, Devlin Junker wrote: > And here is the stack trace. Sorry about sending multiple emails. > > java.util.ConcurrentModificationException: Iterator: started at 6, now 7 > at > com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.policyError(DatasetControlMRSW.java:157) > at > com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.access$000(DatasetControlMRSW.java:32) > at > com.hp.hpl.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.checkCourrentModification(DatasetControlMRSW.java:110) > at > com.hp.hpl.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.hasNext(DatasetControlMRSW.java:118) > at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318) > at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318) > at org.apache.jena.atlas.iterator.Iter.hasNext(Iter.java:916) > at > com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90) > at > com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90) > at > com.hp.hpl.jena.util.iterator.FilterIterator.hasNext(FilterIterator.java:54) > at > com.hp.hpl.jena.graph.compose.CompositionBase$2.hasNext(CompositionBase.java:94) > at > com.hp.hpl.jena.util.iterator.NiceIterator$1.hasNext(NiceIterator.java:103) > at > com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90) > at > com.hp.hpl.jena.util.iterator.NiceIterator$1.hasNext(NiceIterator.java:103) > at > com.hp.hpl.jena.util.iterator.NiceIterator$1.hasNext(NiceIterator.java:103) > at > com.hp.hpl.jena.reasoner.rulesys.impl.TopLevelTripleMatchFrame.nextMatch(TopLevelTripleMatchFrame.java:55) > at > com.hp.hpl.jena.reasoner.rulesys.impl.LPInterpreter.run(LPInterpreter.java:327) > at > com.hp.hpl.jena.reasoner.rulesys.impl.LPInterpreter.next(LPInterpreter.java:189) > at com.hp.hpl.jena.reasoner.rulesys.impl.Generator.pump(Generator.java:253) > at > com.hp.hpl.jena.reasoner.rulesys.impl.Generator.pump(Generator.java:240) > at > com.hp.hpl.jena.reasoner.rulesys.impl.LPBRuleEngine.pump(LPBRuleEngine.java:311) > at > com.hp.hpl.jena.reasoner.rulesys.impl.LPTopGoalIterator.moveForward(LPTopGoalIterator.java:107) > at > com.hp.hpl.jena.reasoner.rulesys.impl.LPTopGoalIterator.hasNext(LPTopGoalIterator.java:222) > at > com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90) > at > com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90) > at > com.hp.hpl.jena.util.iterator.FilterIterator.hasNext(FilterIterator.java:54) > at > com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90) > at > com.hp.hpl.jena.util.iterator.FilterIterator.hasNext(FilterIterator.java:54) > at > com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90) > at > com.hp.hpl.jena.util.iterator.FilterIterator.hasNext(FilterIterator.java:54) > at > com.hp.hpl.jena.graph.compose.CompositionBase$2.hasNext(CompositionBase.java:94) > at > com.hp.hpl.jena.util.iterator.NiceIterator$1.hasNext(NiceIterator.java:103) > at > com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90) > at > com.hp.hpl.jena.util.iterator.NiceIterator$1.hasNext(NiceIterator.java:103) > at > com.hp.hpl.jena.util.iterator.NiceIterator$1.hasNext(NiceIterator.java:103) > at > com.hp.hpl.jena.reasoner.rulesys.impl.TopLevelTripleMatchFrame.nextMatch(TopLevelTripleMatchFrame.java:55) > at > com.hp.hpl.jena.reasoner.rulesys.impl.LPInterpreter.run(LPInterpreter.java:327) > at > com.hp.hpl.jena.reasoner.rulesys.impl.LPInterpreter.next(LPInterpreter.java:189) > at > com.hp.hpl.jena.reasoner.rulesys.impl.LPTopGoalIterator.moveForward(LPTopGoalIterator.java:98) > at > com.hp.hpl.jena.reasoner.rulesys.impl.LPTopGoalIterator.hasNext(LPTopGoalIterator.java:222) > at > com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90) > at > com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90) > at > com.hp.hpl.jena.util.iterator.FilterIterator.hasNext(FilterIterator.java:54) > at > com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90) > at > com.hp.hpl.jena.util.iterator.FilterIterator.hasNext(FilterIterator.java:54) > at > com.hp.hpl.jena.graph.impl.GraphBase.containsByFind(GraphBase.java:331) > at > com.hp.hpl.jena.graph.impl.GraphBase.graphBaseContains(GraphBase.java:309) > at com.hp.hpl.jena.graph.impl.GraphBase.contains(GraphBase.java:301) > at com.hp.hpl.jena.graph.impl.GraphBase.contains(GraphBase.java:318) > at com.hp.hpl.jena.rdf.model.impl.ModelCom.contains(ModelCom.java:1222) > at > com.hp.hpl.jena.rdf.model.impl.ResourceIm
Re: ConcurrentModificationException responding to View Request's
And here is the stack trace. Sorry about sending multiple emails. java.util.ConcurrentModificationException: Iterator: started at 6, now 7 at com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.policyError(DatasetControlMRSW.java:157) at com.hp.hpl.jena.tdb.sys.DatasetControlMRSW.access$000(DatasetControlMRSW.java:32) at com.hp.hpl.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.checkCourrentModification(DatasetControlMRSW.java:110) at com.hp.hpl.jena.tdb.sys.DatasetControlMRSW$IteratorCheckNotConcurrent.hasNext(DatasetControlMRSW.java:118) at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318) at org.apache.jena.atlas.iterator.Iter$4.hasNext(Iter.java:318) at org.apache.jena.atlas.iterator.Iter.hasNext(Iter.java:916) at com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90) at com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90) at com.hp.hpl.jena.util.iterator.FilterIterator.hasNext(FilterIterator.java:54) at com.hp.hpl.jena.graph.compose.CompositionBase$2.hasNext(CompositionBase.java:94) at com.hp.hpl.jena.util.iterator.NiceIterator$1.hasNext(NiceIterator.java:103) at com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90) at com.hp.hpl.jena.util.iterator.NiceIterator$1.hasNext(NiceIterator.java:103) at com.hp.hpl.jena.util.iterator.NiceIterator$1.hasNext(NiceIterator.java:103) at com.hp.hpl.jena.reasoner.rulesys.impl.TopLevelTripleMatchFrame.nextMatch(TopLevelTripleMatchFrame.java:55) at com.hp.hpl.jena.reasoner.rulesys.impl.LPInterpreter.run(LPInterpreter.java:327) at com.hp.hpl.jena.reasoner.rulesys.impl.LPInterpreter.next(LPInterpreter.java:189) at com.hp.hpl.jena.reasoner.rulesys.impl.Generator.pump(Generator.java:253) at com.hp.hpl.jena.reasoner.rulesys.impl.Generator.pump(Generator.java:240) at com.hp.hpl.jena.reasoner.rulesys.impl.LPBRuleEngine.pump(LPBRuleEngine.java:311) at com.hp.hpl.jena.reasoner.rulesys.impl.LPTopGoalIterator.moveForward(LPTopGoalIterator.java:107) at com.hp.hpl.jena.reasoner.rulesys.impl.LPTopGoalIterator.hasNext(LPTopGoalIterator.java:222) at com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90) at com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90) at com.hp.hpl.jena.util.iterator.FilterIterator.hasNext(FilterIterator.java:54) at com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90) at com.hp.hpl.jena.util.iterator.FilterIterator.hasNext(FilterIterator.java:54) at com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90) at com.hp.hpl.jena.util.iterator.FilterIterator.hasNext(FilterIterator.java:54) at com.hp.hpl.jena.graph.compose.CompositionBase$2.hasNext(CompositionBase.java:94) at com.hp.hpl.jena.util.iterator.NiceIterator$1.hasNext(NiceIterator.java:103) at com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90) at com.hp.hpl.jena.util.iterator.NiceIterator$1.hasNext(NiceIterator.java:103) at com.hp.hpl.jena.util.iterator.NiceIterator$1.hasNext(NiceIterator.java:103) at com.hp.hpl.jena.reasoner.rulesys.impl.TopLevelTripleMatchFrame.nextMatch(TopLevelTripleMatchFrame.java:55) at com.hp.hpl.jena.reasoner.rulesys.impl.LPInterpreter.run(LPInterpreter.java:327) at com.hp.hpl.jena.reasoner.rulesys.impl.LPInterpreter.next(LPInterpreter.java:189) at com.hp.hpl.jena.reasoner.rulesys.impl.LPTopGoalIterator.moveForward(LPTopGoalIterator.java:98) at com.hp.hpl.jena.reasoner.rulesys.impl.LPTopGoalIterator.hasNext(LPTopGoalIterator.java:222) at com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90) at com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90) at com.hp.hpl.jena.util.iterator.FilterIterator.hasNext(FilterIterator.java:54) at com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90) at com.hp.hpl.jena.util.iterator.FilterIterator.hasNext(FilterIterator.java:54) at com.hp.hpl.jena.graph.impl.GraphBase.containsByFind(GraphBase.java:331) at com.hp.hpl.jena.graph.impl.GraphBase.graphBaseContains(GraphBase.java:309) at com.hp.hpl.jena.graph.impl.GraphBase.contains(GraphBase.java:301) at com.hp.hpl.jena.graph.impl.GraphBase.contains(GraphBase.java:318) at com.hp.hpl.jena.rdf.model.impl.ModelCom.contains(ModelCom.java:1222) at com.hp.hpl.jena.rdf.model.impl.ResourceImpl.hasProperty(ResourceImpl.java:340) at com.hp.hpl.jena.ontology.impl.OntClassImpl.isRestriction(OntClassImpl.java:868) at com.eduworks.ontology.OntologyClass.getJSONRepresentation(OntologyClass.java:457) at com.eduworks.ontology.OntologyInstance.createInstance(OntologyInstance.java:64) at com.eduworks.ontology.Ontology.createInstance(Ontology.java:396) at com.eduworks.ontology.test.TestOntology.test_LoadExternalStructure(TestOntology.java:334) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMet
Re: ConcurrentModificationException responding to View Request's
I forgot to mention that this is happening during a Write Transaction on
the Dataset, in case that is important.
Devlin
On Wed, Aug 13, 2014 at 9:19 AM, Devlin Junker
wrote:
> Hi,
>
> I am having a little bit of trouble implementing the TDB store for my Jena
> Ontologies. I have been able to solve most of the issues that I've come
> across, but I have become frustrated with the view request functions that
> the Ontology objects define.
>
> I am trying to get a list of all of the restrictions that define a certain
> OntClass, but while I am looping through all of the superclasses for the
> class I receive a ConcurrentModificationException when calling the
> is[Restriction, DatatypeProperty, and SomeValuesFromRestriction] calls.
>
> Apparently it is happening when finding the triple on the graph that would
> define it as the certain view type. The exception is thrown on the
> iterator.hasNext in GraphBase.containsByFind().
>
> The application I am running is only single threaded (I think, it is in a
> JUnit Test Case) so I don't think any other modifications should actually
> be happening to the Dataset while I am checking against the View Type.
>
> I've included the important code below and highlighted the area where the
> exception is thrown.
>
> Thanks for any help you can offer,
> Devlin
>
> List supers = jenaClass.listSuperClasses().toList();
>
> for(int index = 0; index < supers.size(); index++){
> OntClass cls = supers.get(index);
> if(cls.isRestriction()){
> Restriction r = cls.asRestriction();
> String valueId = "";
> OntProperty prop = r.getOnProperty();
> Resource restrictionValue;
>
> if(r.isAllValuesFromRestriction()){
> restrictionValue = r.asAllValuesFromRestriction().getAllValuesFrom();
> }else if(r.isSomeValuesFromRestriction()){
> restrictionValue = r.asSomeValuesFromRestriction().getSomeValuesFrom();
> }else{
> // TODO: Implement Cardinality Restrictions
> throw new RuntimeException("Unexpected Restriction Type");
> }
> if(prop.isDatatypeProperty()){
> // TODO: More DataTypes
> if(restrictionValue.equals(XSD.xint) ||
> restrictionValue.equals(XSD.integer)){
> valueId = "xsd:integer";
> }else if(restrictionValue.equals(XSD.xstring)){
> valueId = "xsd:string";
> }else if(restrictionValue.equals(XSD.xdouble)){
> valueId = "xsd:double";
> }else if(restrictionValue.equals(XSD.dateTime)){
> valueId = "xsd:dateTime";
> }else{
> throw new RuntimeException("Unrecognized DataType:
> "+restrictionValue.toString());
> }
> }else{
> valueId = getIdentifier(restrictionValue.getURI());
> }
> try{
> if(r.isAllValuesFromRestriction()){
> JSONArray restriction = rest.optJSONArray(getIdentifier(prop.getURI()));
> if(restriction == null || !restriction.toString().contains(valueId)){
> rest.append(getIdentifier(prop.getURI()), valueId);
> }
> }else if(r.isSomeValuesFromRestriction()){
> JSONArray requirement = req.optJSONArray(getIdentifier(prop.getURI()));
> // TODO: HACK (For some reason during update I am getting duplicate of the
> some value restrictions)
> if(requirement == null || !requirement.toString().contains(valueId)){
> req.append(getIdentifier(prop.getURI()), valueId);
> }
> }else{
> // TODO: Implement Cardinality Restrictions
> throw new RuntimeException("Unexpected Restriction Type");
> }
> }catch(JSONException e){
> throw new RuntimeException("Error Creating JSON Object for Property " +
> prop);
> }
> }
> }
>
