subject:"QueryParseException\: java.lang.StackOverflowError"

Re: QueryParseException: java.lang.StackOverflowError

2017-03-01 Thread Laurent Rucquoy

Thank you for your help.
I'll try the ARQ parser.
Sincerely,
Laurent


On 22 February 2017 at 17:12, Andy Seaborne  wrote:

> Now that standards are settled, we could consider making SPARQL 1.1 have
> this change.  It is not a language change, it is only a grammar change
> (different grammar accepting and rejecting the same language).
>
> The spec grammar is simple LL(1) - the rewrite uses a javacc feature and
> so its not pure LL(1).
>
> (if Java had tail recursion optimization this would not be necessary ...)
>
> Andy
>
>
> On 22/02/17 14:44, Rob Vesse wrote:
>
>> The standard SPARQL 1.1 parser strictly follows the grammar. The grammar
>> is recursive which can lead to stack overflow errors when there are too
>> many individual updates within the overall update request. If you use the
>> ARQ Version of the parser it uses a slightly modified modified version of
>> the grammar which avoids this issue.
>>
>>  Rob
>>
>> On 22/02/2017 14:21, "Laurent Rucquoy" 
>> wrote:
>>
>> Hello,
>>
>> We are currently working on TDB data migrations.
>> These migrations imply massive writing operations using SPARQL update
>> queries passed through UpdateAction.parseExecute(String
>> updateString, Model
>> model)
>>
>> To improve migrations runtime duration, we decided to group several
>> "unit"
>> update queries per transaction (please see the "unit" update query
>> sample
>> here below.)
>> We noted that when the "unit" update queries group size passes a
>> threshold
>> (about 250 "unit" updates), we get the stack overflow errors (please
>> see
>> the corresponding stacktrace here below.)
>>
>> Do I do something wrong?
>> Are there recommendations about some limits?
>>
>> Thank you in advance for your help.
>> Best regards,
>> Laurent
>>
>>
>>
>> "Unit" update query sample:
>>
>>
>> DELETE {
>> > c2e715babac2>
>>  ?annotationType ;
>>  ?annotationUpdatedTime .
>> }
>> INSERT {
>> > c2e715babac2>
>>  <
>> http://company.com/model/Annotation> ;
>> 
>> "2017-02-17T15:49:52.705Z"^^<
>> http://www.w3.org/2001/XMLSchema#dateTime> .
>> }
>> WHERE {
>> OPTIONAL {
>> <
>> http://company.com/data/Annotation/ffa19568-9300-477f-4d5c-
>> c2e715babac2> <
>> http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?annotationType .
>> }
>> OPTIONAL {
>> <
>> http://company.com/data/Annotation/ffa19568-9300-477f-4d5c-
>> c2e715babac2> <
>> http://company.com/model/updated> ?annotationUpdatedTime .
>> }
>> } ;
>> DELETE {
>> > c2e715babac2>
>>  ?annotationUser .
>> }
>> INSERT {
>> > c2e715babac2>
>>  <
>> http://company.com/data/User/Default/0684d3b0-dba8-43c8-9177
>> -eb5892375032> .
>> }
>> WHERE {
>> OPTIONAL {
>> <
>> http://company.com/data/Annotation/ffa19568-9300-477f-4d5c-
>> c2e715babac2> <
>> http://company.com/model/modifiedBy> ?annotationUser .
>> }
>> } ;
>> DELETE {
>> <
>> http://company.com/data/User/Default/0684d3b0-dba8-43c8-9177
>> -eb5892375032> <
>> http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?userType ;
>>  ?userLoginName ;
>>  ?userUid .
>> }
>> INSERT {
>> <
>> http://company.com/data/User/Default/0684d3b0-dba8-43c8-9177
>> -eb5892375032> <
>> http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <
>> http://company.com/model/User> ;
>>  "***" ;
>> 
>> "0684d3b0-dba8-43c8-9177-eb5892375032" .
>> }
>> WHERE {
>> OPTIONAL {
>> <
>> http://company.com/data/User/Default/0684d3b0-dba8-43c8-9177
>> -eb5892375032> <
>> http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?userType .
>> }
>> OPTIONAL {
>> <
>> http://company.com/data/User/Default/0684d3b0-dba8-43c8-9177
>> -eb5892375032> <
>> http://company.com/model/loginName> ?userLoginName .
>> }
>> OPTIONAL {
>> <
>> http://company.com/data/User/Default/0684d3b0-dba8-43c8-9177
>> -eb5892375032> <
>> http://company.com/model/uid> ?userUid .

Re: QueryParseException: java.lang.StackOverflowError

2017-02-22 Thread Andy Seaborne

Now that standards are settled, we could consider making SPARQL 1.1 have 
this change.  It is not a language change, it is only a grammar change 
(different grammar accepting and rejecting the same language).


The spec grammar is simple LL(1) - the rewrite uses a javacc feature and 
so its not pure LL(1).


(if Java had tail recursion optimization this would not be necessary ...)

Andy

On 22/02/17 14:44, Rob Vesse wrote:

The standard SPARQL 1.1 parser strictly follows the grammar. The grammar is 
recursive which can lead to stack overflow errors when there are too many 
individual updates within the overall update request. If you use the ARQ 
Version of the parser it uses a slightly modified modified version of the 
grammar which avoids this issue.

 Rob

On 22/02/2017 14:21, "Laurent Rucquoy"  wrote:

Hello,

We are currently working on TDB data migrations.
These migrations imply massive writing operations using SPARQL update
queries passed through UpdateAction.parseExecute(String updateString, Model
model)

To improve migrations runtime duration, we decided to group several "unit"
update queries per transaction (please see the "unit" update query sample
here below.)
We noted that when the "unit" update queries group size passes a threshold
(about 250 "unit" updates), we get the stack overflow errors (please see
the corresponding stacktrace here below.)

Do I do something wrong?
Are there recommendations about some limits?

Thank you in advance for your help.
Best regards,
Laurent



"Unit" update query sample:


DELETE {


 ?annotationType ;
 ?annotationUpdatedTime .
}
INSERT {


 <
http://company.com/model/Annotation> ;
 "2017-02-17T15:49:52.705Z"^^<
http://www.w3.org/2001/XMLSchema#dateTime> .
}
WHERE {
OPTIONAL {
<
http://company.com/data/Annotation/ffa19568-9300-477f-4d5c-c2e715babac2> <
http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?annotationType .
}
OPTIONAL {
<
http://company.com/data/Annotation/ffa19568-9300-477f-4d5c-c2e715babac2> <
http://company.com/model/updated> ?annotationUpdatedTime .
}
} ;
DELETE {


 ?annotationUser .
}
INSERT {


 <
http://company.com/data/User/Default/0684d3b0-dba8-43c8-9177-eb5892375032> .
}
WHERE {
OPTIONAL {
<
http://company.com/data/Annotation/ffa19568-9300-477f-4d5c-c2e715babac2> <
http://company.com/model/modifiedBy> ?annotationUser .
}
} ;
DELETE {
<
http://company.com/data/User/Default/0684d3b0-dba8-43c8-9177-eb5892375032> <
http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?userType ;
 ?userLoginName ;
 ?userUid .
}
INSERT {
<
http://company.com/data/User/Default/0684d3b0-dba8-43c8-9177-eb5892375032> <
http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <
http://company.com/model/User> ;
 "***" ;

"0684d3b0-dba8-43c8-9177-eb5892375032" .
}
WHERE {
OPTIONAL {
<
http://company.com/data/User/Default/0684d3b0-dba8-43c8-9177-eb5892375032> <
http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?userType .
}
OPTIONAL {
<
http://company.com/data/User/Default/0684d3b0-dba8-43c8-9177-eb5892375032> <
http://company.com/model/loginName> ?userLoginName .
}
OPTIONAL {
<
http://company.com/data/User/Default/0684d3b0-dba8-43c8-9177-eb5892375032> <
http://company.com/model/uid> ?userUid .
}
} ;
DELETE {


 ?target .
}
INSERT {


 <

http://company.com/data/Image/1.2.840.114619.2.327.3.2474926736.930.1452584764.259.503>
.
}
WHERE {
OPTIONAL {
<

Re: QueryParseException: java.lang.StackOverflowError

2017-02-22 Thread Rob Vesse

The standard SPARQL 1.1 parser strictly follows the grammar. The grammar is 
recursive which can lead to stack overflow errors when there are too many 
individual updates within the overall update request. If you use the ARQ 
Version of the parser it uses a slightly modified modified version of the 
grammar which avoids this issue.

 Rob

On 22/02/2017 14:21, "Laurent Rucquoy"  wrote:

Hello,

We are currently working on TDB data migrations.
These migrations imply massive writing operations using SPARQL update
queries passed through UpdateAction.parseExecute(String updateString, Model
model)

To improve migrations runtime duration, we decided to group several "unit"
update queries per transaction (please see the "unit" update query sample
here below.)
We noted that when the "unit" update queries group size passes a threshold
(about 250 "unit" updates), we get the stack overflow errors (please see
the corresponding stacktrace here below.)

Do I do something wrong?
Are there recommendations about some limits?

Thank you in advance for your help.
Best regards,
Laurent



"Unit" update query sample:


DELETE {


 ?annotationType ;
 ?annotationUpdatedTime .
}
INSERT {


 <
http://company.com/model/Annotation> ;
 "2017-02-17T15:49:52.705Z"^^<
http://www.w3.org/2001/XMLSchema#dateTime> .
}
WHERE {
OPTIONAL {
<
http://company.com/data/Annotation/ffa19568-9300-477f-4d5c-c2e715babac2> <
http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?annotationType .
}
OPTIONAL {
<
http://company.com/data/Annotation/ffa19568-9300-477f-4d5c-c2e715babac2> <
http://company.com/model/updated> ?annotationUpdatedTime .
}
} ;
DELETE {


 ?annotationUser .
}
INSERT {


 <
http://company.com/data/User/Default/0684d3b0-dba8-43c8-9177-eb5892375032> .
}
WHERE {
OPTIONAL {
<
http://company.com/data/Annotation/ffa19568-9300-477f-4d5c-c2e715babac2> <
http://company.com/model/modifiedBy> ?annotationUser .
}
} ;
DELETE {
<
http://company.com/data/User/Default/0684d3b0-dba8-43c8-9177-eb5892375032> <
http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?userType ;
 ?userLoginName ;
 ?userUid .
}
INSERT {
<
http://company.com/data/User/Default/0684d3b0-dba8-43c8-9177-eb5892375032> <
http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <
http://company.com/model/User> ;
 "***" ;

"0684d3b0-dba8-43c8-9177-eb5892375032" .
}
WHERE {
OPTIONAL {
<
http://company.com/data/User/Default/0684d3b0-dba8-43c8-9177-eb5892375032> <
http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?userType .
}
OPTIONAL {
<
http://company.com/data/User/Default/0684d3b0-dba8-43c8-9177-eb5892375032> <
http://company.com/model/loginName> ?userLoginName .
}
OPTIONAL {
<
http://company.com/data/User/Default/0684d3b0-dba8-43c8-9177-eb5892375032> <
http://company.com/model/uid> ?userUid .
}
} ;
DELETE {


 ?target .
}
INSERT {


 <

http://company.com/data/Image/1.2.840.114619.2.327.3.2474926736.930.1452584764.259.503>
.
}
WHERE {
OPTIONAL {
<
http://company.com/data/Annotation/ffa19568-9300-477f-4d5c-c2e715babac2> <
http://company.com/model/hasTarget> ?target .
}
} ;
DELETE {
<

http://company.com/data/Image/1.2.840.114619.2.327.3.2474926736.930.1452584764.259.503>
 ?imageType ;
 ?imageSopInstanceUid .
}
INSERT {
<

QueryParseException: java.lang.StackOverflowError

2017-02-22 Thread Laurent Rucquoy

Hello,

We are currently working on TDB data migrations.
These migrations imply massive writing operations using SPARQL update
queries passed through UpdateAction.parseExecute(String updateString, Model
model)

To improve migrations runtime duration, we decided to group several "unit"
update queries per transaction (please see the "unit" update query sample
here below.)
We noted that when the "unit" update queries group size passes a threshold
(about 250 "unit" updates), we get the stack overflow errors (please see
the corresponding stacktrace here below.)

Do I do something wrong?
Are there recommendations about some limits?

Thank you in advance for your help.
Best regards,
Laurent



"Unit" update query sample:


DELETE {

 ?annotationType ;
 ?annotationUpdatedTime .
}
INSERT {

 <
http://company.com/model/Annotation> ;
 "2017-02-17T15:49:52.705Z"^^<
http://www.w3.org/2001/XMLSchema#dateTime> .
}
WHERE {
OPTIONAL {
<
http://company.com/data/Annotation/ffa19568-9300-477f-4d5c-c2e715babac2> <
http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?annotationType .
}
OPTIONAL {
<
http://company.com/data/Annotation/ffa19568-9300-477f-4d5c-c2e715babac2> <
http://company.com/model/updated> ?annotationUpdatedTime .
}
} ;
DELETE {

 ?annotationUser .
}
INSERT {

 <
http://company.com/data/User/Default/0684d3b0-dba8-43c8-9177-eb5892375032> .
}
WHERE {
OPTIONAL {
<
http://company.com/data/Annotation/ffa19568-9300-477f-4d5c-c2e715babac2> <
http://company.com/model/modifiedBy> ?annotationUser .
}
} ;
DELETE {
<
http://company.com/data/User/Default/0684d3b0-dba8-43c8-9177-eb5892375032> <
http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?userType ;
 ?userLoginName ;
 ?userUid .
}
INSERT {
<
http://company.com/data/User/Default/0684d3b0-dba8-43c8-9177-eb5892375032> <
http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <
http://company.com/model/User> ;
 "***" ;

"0684d3b0-dba8-43c8-9177-eb5892375032" .
}
WHERE {
OPTIONAL {
<
http://company.com/data/User/Default/0684d3b0-dba8-43c8-9177-eb5892375032> <
http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?userType .
}
OPTIONAL {
<
http://company.com/data/User/Default/0684d3b0-dba8-43c8-9177-eb5892375032> <
http://company.com/model/loginName> ?userLoginName .
}
OPTIONAL {
<
http://company.com/data/User/Default/0684d3b0-dba8-43c8-9177-eb5892375032> <
http://company.com/model/uid> ?userUid .
}
} ;
DELETE {

 ?target .
}
INSERT {

 <
http://company.com/data/Image/1.2.840.114619.2.327.3.2474926736.930.1452584764.259.503>
.
}
WHERE {
OPTIONAL {
<
http://company.com/data/Annotation/ffa19568-9300-477f-4d5c-c2e715babac2> <
http://company.com/model/hasTarget> ?target .
}
} ;
DELETE {
<
http://company.com/data/Image/1.2.840.114619.2.327.3.2474926736.930.1452584764.259.503>
 ?imageType ;
 ?imageSopInstanceUid .
}
INSERT {
<
http://company.com/data/Image/1.2.840.114619.2.327.3.2474926736.930.1452584764.259.503>
 <
http://company.com/model/Image> ;

"1.2.840.114619.2.327.3.2474926736.930.1452584764.259.503" .
}
WHERE {
OPTIONAL {
<
http://company.com/data/Image/1.2.840.114619.2.327.3.2474926736.930.1452584764.259.503>
 ?imageType .
}
OPTIONAL {
<
http://company.com/data/Image/1.2.840.114619.2.327.3.2474926736.930.1452584764.259.503>
 ?imageSopInstanceUid .
}
} ;
DELETE {
<
http://company.com/data/Image/1.2.840.114619.2.327.3.2474926736.930.1452584764.259.503>
 ?imageSeries .
}
INSERT {
<

Re: QueryParseException: java.lang.StackOverflowError

Re: QueryParseException: java.lang.StackOverflowError

Re: QueryParseException: java.lang.StackOverflowError

QueryParseException: java.lang.StackOverflowError

4 matches

Site Navigation

Mail list logo

Footer information