You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by "Kruiger, J.F. (Han)" <ha...@tno.nl.INVALID> on 2021/10/11 10:04:17 UTC
Possible bug when querying
Hi there,
We are running into an issue that seems like a bug in Jena 4.2.0.
A (reasonably) minimal example is in this test case:
https://github.com/barrynl/jena-example/blob/cf2da8e5c7cd9a0f415282486ec8472e53d0a9c4/src/main/java/nl/tno/ict/ds/cb/jena/JenaRepeatedQueryOnInfModelTest.java
What happens there is:
* An `InfModel` is created from a reasoner that is bound to some RDF
data.
* The triples from the `InfModel` are written to a file `before.ttl`,
for debugging.
* A SELECT query is fired on the model repeatedly.
* After this, the triples from the same model are written to
`after.ttl`, for debugging.
The expected behaviour is:
* Since nothing changes in the model, the results of the subsequent
SELECT queries should be identical.
* `before.ttl` and `after.ttl` should be identical.
However, both of those things do not happen in the actual behaviour.
What we see (tested on my Linux machine, and my colleague's Windows
machine) is the following:
* For the first ~100 query results, there are not matches found and
the empty binding set is returned. (This is correct!)
* After that, something mysterious happens and the query suddenly
gives a binding as a result. (This is incorrect!)
* In `before.ttl`, both instances in the triple data are (correctly)
classified as `ic:InformPurpose` and `ic:Purpose`, but in
`after.ttl`, one of the resources is not classified as `ic:Purpose`
anymore (even though the model hasn't changed; only SELECT queries
were fired).
Note that this behaviour does not occur when we use Jena 4.1.0.
Are we missing something, or is this indeed a bug?
Best,
Han Kruiger
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
Re: Possible bug when querying
Posted by Andy Seaborne <an...@apache.org>.
Thanks for the confirmation.
We've managed to convert the example to a java code test case that
follows the calls that the SPARQL engine would make.
It looks like the changes in 4.1->4.2 are uncovering an existing condition.
It is sensitive to the order the code executes in and also any other
places that touch the graph (this is why writing the graph changed the
situation).
Andy
On 18/10/2021 09:31, Kruiger, J.F. (Han) wrote:
> Hi Andy, Barry,
>
> I can also confirm this. I removed both `infModel.write` lines, and it
> gives me the incorrect result every time.
>
> I also use OpenJDK 14.0.2:
>
> ```
> java -version
> openjdk version "14.0.2" 2020-07-14
> OpenJDK Runtime Environment (build 14.0.2+12-Ubuntu-120.04)
> OpenJDK 64-Bit Server VM (build 14.0.2+12-Ubuntu-120.04, mixed mode,
> sharing)
> ```
>
> Best,
> Han
>
> On Thu, 2021-10-14 at 18:26 +0100, Andy Seaborne wrote:
>>
>> On 14/10/2021 12:48, Nouwt, B. (Barry) wrote:
>>> Hi Andy, apart from Han I also gave this issue a try and indeed, if
>>> I remove those lines, it gives me the incorrect result from the
>>> first iteration.
>>>
>>> I test it with Oracle's JDK version 14.0.2.
>>>
>>> Hope this helps!
>>
>> Yes, thanks.
>>
>> The myserty narrows ... but simply reversing the commit on the
>> current
>> development does not fix the problem.
>>
>>> Best regards, Barry
>>>
>>> -----Original Message-----
>>> From: Andy Seaborne <an...@apache.org>
>>> Sent: donderdag 14 oktober 2021 12:36
>>> To: users@jena.apache.org
>>> Subject: Re: Possible bug when querying
>>>
>>> Hi Han,
>>>
>>> Could you confirm something for me please?
>>>
>>> If you remove both the "infModel.write", then it fails first loop
>>> iteration every time.
>>>
>>> Also - which JDK and version are you running?
>>>
>>> Andy
>>>
>>> git-bisect says commit c1c9d48a4f but that isn't obviously the root
>>> cause and it may be merely the trigger for something that has been
>>> a latent problem for longer.
>>>
>>> On 12/10/2021 08:13, Kruiger, J.F. (Han) wrote:
>>>> Thanks, Andy!
>>>>
>>>> On Mon, 2021-10-11 at 22:15 +0100, Andy Seaborne wrote:
>>>>> Hi Han,
>>>>>
>>>>> Yes, it appears to be a bug. I can recreate it although I had
>>>>> to
>>>>> increase the loop count to 5000 to see anything going wrong.
>>>>>
>>>>> It looks like once the test is wrong, it is wrong for 10+
>>>>> iterations
>>>>> afterwards, becomes OK again, and maybe goes wrong again. Quite
>>>>> strange, and no concurrency in sight.
>>>>>
>>>>> If the test is changed to use a plain model with the
>>>>> materialised
>>>>> inference model copied into it, it does not go wrong.
>>>>>
>>>>> Recorded: JENA-2184
>>>>>
>>>>> Andy
>>>>>
>>>>> https://issues.apache.org/jira/browse/JENA-2184
>>>>>
>>>>> On 11/10/2021 11:04, Kruiger, J.F. (Han) wrote:
>>>>>> Hi there,
>>>>>>
>>>>>> We are running into an issue that seems like a bug in Jena
>>>>>> 4.2.0.
>>>>>>
>>>>>> A (reasonably) minimal example is in this test case:
>>>>>> https://github.com/barrynl/jena-example/blob/cf2da8e5c7cd9a0f4152824
>>>>>> 86ec8472e53d0a9c4/src/main/java/nl/tno/ict/ds/cb/jena/JenaRep
>>>>>> eatedQu
>>>>>> eryOnInfModelTest.java
>>>>>>
>>>>>> What happens there is:
>>>>>>
>>>>>> * An `InfModel` is created from a reasoner that is bound
>>>>>> to some
>>>>>> RDF
>>>>>> data.
>>>>>> * The triples from the `InfModel` are written to a file
>>>>>> `before.ttl`,
>>>>>> for debugging.
>>>>>> * A SELECT query is fired on the model repeatedly.
>>>>>> * After this, the triples from the same model are written
>>>>>> to
>>>>>> `after.ttl`, for debugging.
>>>>>>
>>>>>> The expected behaviour is:
>>>>>>
>>>>>> * Since nothing changes in the model, the results of the
>>>>>> subsequent
>>>>>> SELECT queries should be identical.
>>>>>> * `before.ttl` and `after.ttl` should be identical.
>>>>>>
>>>>>> However, both of those things do not happen in the actual
>>>>>> behaviour.
>>>>>>
>>>>>> What we see (tested on my Linux machine, and my colleague's
>>>>>> Windows
>>>>>> machine) is the following:
>>>>>>
>>>>>> * For the first ~100 query results, there are not matches
>>>>>> found
>>>>>> and
>>>>>> the empty binding set is returned. (This is correct!)
>>>>>> * After that, something mysterious happens and the query
>>>>>> suddenly
>>>>>> gives a binding as a result. (This is incorrect!)
>>>>>> * In `before.ttl`, both instances in the triple data are
>>>>>> (correctly)
>>>>>> classified as `ic:InformPurpose` and `ic:Purpose`, but
>>>>>> in
>>>>>> `after.ttl`, one of the resources is not classified as
>>>>>> `ic:Purpose`
>>>>>> anymore (even though the model hasn't changed; only
>>>>>> SELECT
>>>>>> queries
>>>>>> were fired).
>>>>>>
>>>>>> Note that this behaviour does not occur when we use Jena
>>>>>> 4.1.0.
>>>>>>
>>>>>> Are we missing something, or is this indeed a bug?
>>>>>>
>>>>>> Best,
>>>>>> Han Kruiger
>>>>>> This message may contain information that is not intended for
>>>>>> you.
>>>>>> If you are not the addressee or if this message was sent to
>>>>>> you by
>>>>>> mistake, you are requested to inform the sender and delete
>>>>>> the
>>>>>> message. TNO accepts no liability for the content of this e-
>>>>>> mail,
>>>>>> for the manner in which you use it and for damage of any kind
>>>>>> resulting from the risks inherent to the electronic
>>>>>> transmission of
>>>>>> messages.
>>>>>>
> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
>
Re: Possible bug when querying
Posted by "Kruiger, J.F. (Han)" <ha...@tno.nl.INVALID>.
Hi Andy, Barry,
I can also confirm this. I removed both `infModel.write` lines, and it
gives me the incorrect result every time.
I also use OpenJDK 14.0.2:
```
java -version
openjdk version "14.0.2" 2020-07-14
OpenJDK Runtime Environment (build 14.0.2+12-Ubuntu-120.04)
OpenJDK 64-Bit Server VM (build 14.0.2+12-Ubuntu-120.04, mixed mode,
sharing)
```
Best,
Han
On Thu, 2021-10-14 at 18:26 +0100, Andy Seaborne wrote:
>
> On 14/10/2021 12:48, Nouwt, B. (Barry) wrote:
> > Hi Andy, apart from Han I also gave this issue a try and indeed, if
> > I remove those lines, it gives me the incorrect result from the
> > first iteration.
> >
> > I test it with Oracle's JDK version 14.0.2.
> >
> > Hope this helps!
>
> Yes, thanks.
>
> The myserty narrows ... but simply reversing the commit on the
> current
> development does not fix the problem.
>
> > Best regards, Barry
> >
> > -----Original Message-----
> > From: Andy Seaborne <an...@apache.org>
> > Sent: donderdag 14 oktober 2021 12:36
> > To: users@jena.apache.org
> > Subject: Re: Possible bug when querying
> >
> > Hi Han,
> >
> > Could you confirm something for me please?
> >
> > If you remove both the "infModel.write", then it fails first loop
> > iteration every time.
> >
> > Also - which JDK and version are you running?
> >
> > Andy
> >
> > git-bisect says commit c1c9d48a4f but that isn't obviously the root
> > cause and it may be merely the trigger for something that has been
> > a latent problem for longer.
> >
> > On 12/10/2021 08:13, Kruiger, J.F. (Han) wrote:
> > > Thanks, Andy!
> > >
> > > On Mon, 2021-10-11 at 22:15 +0100, Andy Seaborne wrote:
> > > > Hi Han,
> > > >
> > > > Yes, it appears to be a bug. I can recreate it although I had
> > > > to
> > > > increase the loop count to 5000 to see anything going wrong.
> > > >
> > > > It looks like once the test is wrong, it is wrong for 10+
> > > > iterations
> > > > afterwards, becomes OK again, and maybe goes wrong again. Quite
> > > > strange, and no concurrency in sight.
> > > >
> > > > If the test is changed to use a plain model with the
> > > > materialised
> > > > inference model copied into it, it does not go wrong.
> > > >
> > > > Recorded: JENA-2184
> > > >
> > > > Andy
> > > >
> > > > https://issues.apache.org/jira/browse/JENA-2184
> > > >
> > > > On 11/10/2021 11:04, Kruiger, J.F. (Han) wrote:
> > > > > Hi there,
> > > > >
> > > > > We are running into an issue that seems like a bug in Jena
> > > > > 4.2.0.
> > > > >
> > > > > A (reasonably) minimal example is in this test case:
> > > > > https://github.com/barrynl/jena-example/blob/cf2da8e5c7cd9a0f4152824
> > > > > 86ec8472e53d0a9c4/src/main/java/nl/tno/ict/ds/cb/jena/JenaRep
> > > > > eatedQu
> > > > > eryOnInfModelTest.java
> > > > >
> > > > > What happens there is:
> > > > >
> > > > > * An `InfModel` is created from a reasoner that is bound
> > > > > to some
> > > > > RDF
> > > > > data.
> > > > > * The triples from the `InfModel` are written to a file
> > > > > `before.ttl`,
> > > > > for debugging.
> > > > > * A SELECT query is fired on the model repeatedly.
> > > > > * After this, the triples from the same model are written
> > > > > to
> > > > > `after.ttl`, for debugging.
> > > > >
> > > > > The expected behaviour is:
> > > > >
> > > > > * Since nothing changes in the model, the results of the
> > > > > subsequent
> > > > > SELECT queries should be identical.
> > > > > * `before.ttl` and `after.ttl` should be identical.
> > > > >
> > > > > However, both of those things do not happen in the actual
> > > > > behaviour.
> > > > >
> > > > > What we see (tested on my Linux machine, and my colleague's
> > > > > Windows
> > > > > machine) is the following:
> > > > >
> > > > > * For the first ~100 query results, there are not matches
> > > > > found
> > > > > and
> > > > > the empty binding set is returned. (This is correct!)
> > > > > * After that, something mysterious happens and the query
> > > > > suddenly
> > > > > gives a binding as a result. (This is incorrect!)
> > > > > * In `before.ttl`, both instances in the triple data are
> > > > > (correctly)
> > > > > classified as `ic:InformPurpose` and `ic:Purpose`, but
> > > > > in
> > > > > `after.ttl`, one of the resources is not classified as
> > > > > `ic:Purpose`
> > > > > anymore (even though the model hasn't changed; only
> > > > > SELECT
> > > > > queries
> > > > > were fired).
> > > > >
> > > > > Note that this behaviour does not occur when we use Jena
> > > > > 4.1.0.
> > > > >
> > > > > Are we missing something, or is this indeed a bug?
> > > > >
> > > > > Best,
> > > > > Han Kruiger
> > > > > This message may contain information that is not intended for
> > > > > you.
> > > > > If you are not the addressee or if this message was sent to
> > > > > you by
> > > > > mistake, you are requested to inform the sender and delete
> > > > > the
> > > > > message. TNO accepts no liability for the content of this e-
> > > > > mail,
> > > > > for the manner in which you use it and for damage of any kind
> > > > > resulting from the risks inherent to the electronic
> > > > > transmission of
> > > > > messages.
> > > > >
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
Re: Possible bug when querying
Posted by Andy Seaborne <an...@apache.org>.
On 14/10/2021 12:48, Nouwt, B. (Barry) wrote:
> Hi Andy, apart from Han I also gave this issue a try and indeed, if I remove those lines, it gives me the incorrect result from the first iteration.
>
> I test it with Oracle's JDK version 14.0.2.
>
> Hope this helps!
Yes, thanks.
The myserty narrows ... but simply reversing the commit on the current
development does not fix the problem.
>
> Best regards, Barry
>
> -----Original Message-----
> From: Andy Seaborne <an...@apache.org>
> Sent: donderdag 14 oktober 2021 12:36
> To: users@jena.apache.org
> Subject: Re: Possible bug when querying
>
> Hi Han,
>
> Could you confirm something for me please?
>
> If you remove both the "infModel.write", then it fails first loop iteration every time.
>
> Also - which JDK and version are you running?
>
> Andy
>
> git-bisect says commit c1c9d48a4f but that isn't obviously the root cause and it may be merely the trigger for something that has been a latent problem for longer.
>
> On 12/10/2021 08:13, Kruiger, J.F. (Han) wrote:
>> Thanks, Andy!
>>
>> On Mon, 2021-10-11 at 22:15 +0100, Andy Seaborne wrote:
>>> Hi Han,
>>>
>>> Yes, it appears to be a bug. I can recreate it although I had to
>>> increase the loop count to 5000 to see anything going wrong.
>>>
>>> It looks like once the test is wrong, it is wrong for 10+ iterations
>>> afterwards, becomes OK again, and maybe goes wrong again. Quite
>>> strange, and no concurrency in sight.
>>>
>>> If the test is changed to use a plain model with the materialised
>>> inference model copied into it, it does not go wrong.
>>>
>>> Recorded: JENA-2184
>>>
>>> Andy
>>>
>>> https://issues.apache.org/jira/browse/JENA-2184
>>>
>>> On 11/10/2021 11:04, Kruiger, J.F. (Han) wrote:
>>>> Hi there,
>>>>
>>>> We are running into an issue that seems like a bug in Jena 4.2.0.
>>>>
>>>> A (reasonably) minimal example is in this test case:
>>>> https://github.com/barrynl/jena-example/blob/cf2da8e5c7cd9a0f4152824
>>>> 86ec8472e53d0a9c4/src/main/java/nl/tno/ict/ds/cb/jena/JenaRepeatedQu
>>>> eryOnInfModelTest.java
>>>>
>>>> What happens there is:
>>>>
>>>> * An `InfModel` is created from a reasoner that is bound to some
>>>> RDF
>>>> data.
>>>> * The triples from the `InfModel` are written to a file
>>>> `before.ttl`,
>>>> for debugging.
>>>> * A SELECT query is fired on the model repeatedly.
>>>> * After this, the triples from the same model are written to
>>>> `after.ttl`, for debugging.
>>>>
>>>> The expected behaviour is:
>>>>
>>>> * Since nothing changes in the model, the results of the
>>>> subsequent
>>>> SELECT queries should be identical.
>>>> * `before.ttl` and `after.ttl` should be identical.
>>>>
>>>> However, both of those things do not happen in the actual behaviour.
>>>>
>>>> What we see (tested on my Linux machine, and my colleague's Windows
>>>> machine) is the following:
>>>>
>>>> * For the first ~100 query results, there are not matches found
>>>> and
>>>> the empty binding set is returned. (This is correct!)
>>>> * After that, something mysterious happens and the query suddenly
>>>> gives a binding as a result. (This is incorrect!)
>>>> * In `before.ttl`, both instances in the triple data are
>>>> (correctly)
>>>> classified as `ic:InformPurpose` and `ic:Purpose`, but in
>>>> `after.ttl`, one of the resources is not classified as
>>>> `ic:Purpose`
>>>> anymore (even though the model hasn't changed; only SELECT
>>>> queries
>>>> were fired).
>>>>
>>>> Note that this behaviour does not occur when we use Jena 4.1.0.
>>>>
>>>> Are we missing something, or is this indeed a bug?
>>>>
>>>> Best,
>>>> Han Kruiger
>>>> This message may contain information that is not intended for you.
>>>> If you are not the addressee or if this message was sent to you by
>>>> mistake, you are requested to inform the sender and delete the
>>>> message. TNO accepts no liability for the content of this e-mail,
>>>> for the manner in which you use it and for damage of any kind
>>>> resulting from the risks inherent to the electronic transmission of
>>>> messages.
>>>>
RE: Possible bug when querying
Posted by "Nouwt, B. (Barry)" <ba...@tno.nl.INVALID>.
Hi Andy, apart from Han I also gave this issue a try and indeed, if I remove those lines, it gives me the incorrect result from the first iteration.
I test it with Oracle's JDK version 14.0.2.
Hope this helps!
Best regards, Barry
-----Original Message-----
From: Andy Seaborne <an...@apache.org>
Sent: donderdag 14 oktober 2021 12:36
To: users@jena.apache.org
Subject: Re: Possible bug when querying
Hi Han,
Could you confirm something for me please?
If you remove both the "infModel.write", then it fails first loop iteration every time.
Also - which JDK and version are you running?
Andy
git-bisect says commit c1c9d48a4f but that isn't obviously the root cause and it may be merely the trigger for something that has been a latent problem for longer.
On 12/10/2021 08:13, Kruiger, J.F. (Han) wrote:
> Thanks, Andy!
>
> On Mon, 2021-10-11 at 22:15 +0100, Andy Seaborne wrote:
>> Hi Han,
>>
>> Yes, it appears to be a bug. I can recreate it although I had to
>> increase the loop count to 5000 to see anything going wrong.
>>
>> It looks like once the test is wrong, it is wrong for 10+ iterations
>> afterwards, becomes OK again, and maybe goes wrong again. Quite
>> strange, and no concurrency in sight.
>>
>> If the test is changed to use a plain model with the materialised
>> inference model copied into it, it does not go wrong.
>>
>> Recorded: JENA-2184
>>
>> Andy
>>
>> https://issues.apache.org/jira/browse/JENA-2184
>>
>> On 11/10/2021 11:04, Kruiger, J.F. (Han) wrote:
>>> Hi there,
>>>
>>> We are running into an issue that seems like a bug in Jena 4.2.0.
>>>
>>> A (reasonably) minimal example is in this test case:
>>> https://github.com/barrynl/jena-example/blob/cf2da8e5c7cd9a0f4152824
>>> 86ec8472e53d0a9c4/src/main/java/nl/tno/ict/ds/cb/jena/JenaRepeatedQu
>>> eryOnInfModelTest.java
>>>
>>> What happens there is:
>>>
>>> * An `InfModel` is created from a reasoner that is bound to some
>>> RDF
>>> data.
>>> * The triples from the `InfModel` are written to a file
>>> `before.ttl`,
>>> for debugging.
>>> * A SELECT query is fired on the model repeatedly.
>>> * After this, the triples from the same model are written to
>>> `after.ttl`, for debugging.
>>>
>>> The expected behaviour is:
>>>
>>> * Since nothing changes in the model, the results of the
>>> subsequent
>>> SELECT queries should be identical.
>>> * `before.ttl` and `after.ttl` should be identical.
>>>
>>> However, both of those things do not happen in the actual behaviour.
>>>
>>> What we see (tested on my Linux machine, and my colleague's Windows
>>> machine) is the following:
>>>
>>> * For the first ~100 query results, there are not matches found
>>> and
>>> the empty binding set is returned. (This is correct!)
>>> * After that, something mysterious happens and the query suddenly
>>> gives a binding as a result. (This is incorrect!)
>>> * In `before.ttl`, both instances in the triple data are
>>> (correctly)
>>> classified as `ic:InformPurpose` and `ic:Purpose`, but in
>>> `after.ttl`, one of the resources is not classified as
>>> `ic:Purpose`
>>> anymore (even though the model hasn't changed; only SELECT
>>> queries
>>> were fired).
>>>
>>> Note that this behaviour does not occur when we use Jena 4.1.0.
>>>
>>> Are we missing something, or is this indeed a bug?
>>>
>>> Best,
>>> Han Kruiger
>>> This message may contain information that is not intended for you.
>>> If you are not the addressee or if this message was sent to you by
>>> mistake, you are requested to inform the sender and delete the
>>> message. TNO accepts no liability for the content of this e-mail,
>>> for the manner in which you use it and for damage of any kind
>>> resulting from the risks inherent to the electronic transmission of
>>> messages.
>>>
Re: Possible bug when querying
Posted by Andy Seaborne <an...@apache.org>.
Hi Han,
Could you confirm something for me please?
If you remove both the "infModel.write", then it fails first loop
iteration every time.
Also - which JDK and version are you running?
Andy
git-bisect says commit c1c9d48a4f but that isn't obviously the root
cause and it may be merely the trigger for something that has been a
latent problem for longer.
On 12/10/2021 08:13, Kruiger, J.F. (Han) wrote:
> Thanks, Andy!
>
> On Mon, 2021-10-11 at 22:15 +0100, Andy Seaborne wrote:
>> Hi Han,
>>
>> Yes, it appears to be a bug. I can recreate it although I had to
>> increase the loop count to 5000 to see anything going wrong.
>>
>> It looks like once the test is wrong, it is wrong for 10+ iterations
>> afterwards, becomes OK again, and maybe goes wrong again. Quite
>> strange,
>> and no concurrency in sight.
>>
>> If the test is changed to use a plain model with the materialised
>> inference model copied into it, it does not go wrong.
>>
>> Recorded: JENA-2184
>>
>> Andy
>>
>> https://issues.apache.org/jira/browse/JENA-2184
>>
>> On 11/10/2021 11:04, Kruiger, J.F. (Han) wrote:
>>> Hi there,
>>>
>>> We are running into an issue that seems like a bug in Jena 4.2.0.
>>>
>>> A (reasonably) minimal example is in this test case:
>>> https://github.com/barrynl/jena-example/blob/cf2da8e5c7cd9a0f415282486ec8472e53d0a9c4/src/main/java/nl/tno/ict/ds/cb/jena/JenaRepeatedQueryOnInfModelTest.java
>>>
>>> What happens there is:
>>>
>>> * An `InfModel` is created from a reasoner that is bound to some
>>> RDF
>>> data.
>>> * The triples from the `InfModel` are written to a file
>>> `before.ttl`,
>>> for debugging.
>>> * A SELECT query is fired on the model repeatedly.
>>> * After this, the triples from the same model are written to
>>> `after.ttl`, for debugging.
>>>
>>> The expected behaviour is:
>>>
>>> * Since nothing changes in the model, the results of the
>>> subsequent
>>> SELECT queries should be identical.
>>> * `before.ttl` and `after.ttl` should be identical.
>>>
>>> However, both of those things do not happen in the actual
>>> behaviour.
>>>
>>> What we see (tested on my Linux machine, and my colleague's Windows
>>> machine) is the following:
>>>
>>> * For the first ~100 query results, there are not matches found
>>> and
>>> the empty binding set is returned. (This is correct!)
>>> * After that, something mysterious happens and the query suddenly
>>> gives a binding as a result. (This is incorrect!)
>>> * In `before.ttl`, both instances in the triple data are
>>> (correctly)
>>> classified as `ic:InformPurpose` and `ic:Purpose`, but in
>>> `after.ttl`, one of the resources is not classified as
>>> `ic:Purpose`
>>> anymore (even though the model hasn't changed; only SELECT
>>> queries
>>> were fired).
>>>
>>> Note that this behaviour does not occur when we use Jena 4.1.0.
>>>
>>> Are we missing something, or is this indeed a bug?
>>>
>>> Best,
>>> Han Kruiger
>>> This message may contain information that is not intended for you.
>>> If you are not the addressee or if this message was sent to you by
>>> mistake, you are requested to inform the sender and delete the
>>> message. TNO accepts no liability for the content of this e-mail,
>>> for the manner in which you use it and for damage of any kind
>>> resulting from the risks inherent to the electronic transmission of
>>> messages.
>>>
Re: Possible bug when querying
Posted by "Kruiger, J.F. (Han)" <ha...@tno.nl.INVALID>.
Thanks, Andy!
On Mon, 2021-10-11 at 22:15 +0100, Andy Seaborne wrote:
> Hi Han,
>
> Yes, it appears to be a bug. I can recreate it although I had to
> increase the loop count to 5000 to see anything going wrong.
>
> It looks like once the test is wrong, it is wrong for 10+ iterations
> afterwards, becomes OK again, and maybe goes wrong again. Quite
> strange,
> and no concurrency in sight.
>
> If the test is changed to use a plain model with the materialised
> inference model copied into it, it does not go wrong.
>
> Recorded: JENA-2184
>
> Andy
>
> https://issues.apache.org/jira/browse/JENA-2184
>
> On 11/10/2021 11:04, Kruiger, J.F. (Han) wrote:
> > Hi there,
> >
> > We are running into an issue that seems like a bug in Jena 4.2.0.
> >
> > A (reasonably) minimal example is in this test case:
> > https://github.com/barrynl/jena-example/blob/cf2da8e5c7cd9a0f415282486ec8472e53d0a9c4/src/main/java/nl/tno/ict/ds/cb/jena/JenaRepeatedQueryOnInfModelTest.java
> >
> > What happens there is:
> >
> > * An `InfModel` is created from a reasoner that is bound to some
> > RDF
> > data.
> > * The triples from the `InfModel` are written to a file
> > `before.ttl`,
> > for debugging.
> > * A SELECT query is fired on the model repeatedly.
> > * After this, the triples from the same model are written to
> > `after.ttl`, for debugging.
> >
> > The expected behaviour is:
> >
> > * Since nothing changes in the model, the results of the
> > subsequent
> > SELECT queries should be identical.
> > * `before.ttl` and `after.ttl` should be identical.
> >
> > However, both of those things do not happen in the actual
> > behaviour.
> >
> > What we see (tested on my Linux machine, and my colleague's Windows
> > machine) is the following:
> >
> > * For the first ~100 query results, there are not matches found
> > and
> > the empty binding set is returned. (This is correct!)
> > * After that, something mysterious happens and the query suddenly
> > gives a binding as a result. (This is incorrect!)
> > * In `before.ttl`, both instances in the triple data are
> > (correctly)
> > classified as `ic:InformPurpose` and `ic:Purpose`, but in
> > `after.ttl`, one of the resources is not classified as
> > `ic:Purpose`
> > anymore (even though the model hasn't changed; only SELECT
> > queries
> > were fired).
> >
> > Note that this behaviour does not occur when we use Jena 4.1.0.
> >
> > Are we missing something, or is this indeed a bug?
> >
> > Best,
> > Han Kruiger
> > This message may contain information that is not intended for you.
> > If you are not the addressee or if this message was sent to you by
> > mistake, you are requested to inform the sender and delete the
> > message. TNO accepts no liability for the content of this e-mail,
> > for the manner in which you use it and for damage of any kind
> > resulting from the risks inherent to the electronic transmission of
> > messages.
> >
Re: Possible bug when querying
Posted by Andy Seaborne <an...@apache.org>.
Hi Han,
Yes, it appears to be a bug. I can recreate it although I had to
increase the loop count to 5000 to see anything going wrong.
It looks like once the test is wrong, it is wrong for 10+ iterations
afterwards, becomes OK again, and maybe goes wrong again. Quite strange,
and no concurrency in sight.
If the test is changed to use a plain model with the materialised
inference model copied into it, it does not go wrong.
Recorded: JENA-2184
Andy
https://issues.apache.org/jira/browse/JENA-2184
On 11/10/2021 11:04, Kruiger, J.F. (Han) wrote:
> Hi there,
>
> We are running into an issue that seems like a bug in Jena 4.2.0.
>
> A (reasonably) minimal example is in this test case:
> https://github.com/barrynl/jena-example/blob/cf2da8e5c7cd9a0f415282486ec8472e53d0a9c4/src/main/java/nl/tno/ict/ds/cb/jena/JenaRepeatedQueryOnInfModelTest.java
>
> What happens there is:
>
> * An `InfModel` is created from a reasoner that is bound to some RDF
> data.
> * The triples from the `InfModel` are written to a file `before.ttl`,
> for debugging.
> * A SELECT query is fired on the model repeatedly.
> * After this, the triples from the same model are written to
> `after.ttl`, for debugging.
>
> The expected behaviour is:
>
> * Since nothing changes in the model, the results of the subsequent
> SELECT queries should be identical.
> * `before.ttl` and `after.ttl` should be identical.
>
> However, both of those things do not happen in the actual behaviour.
>
> What we see (tested on my Linux machine, and my colleague's Windows
> machine) is the following:
>
> * For the first ~100 query results, there are not matches found and
> the empty binding set is returned. (This is correct!)
> * After that, something mysterious happens and the query suddenly
> gives a binding as a result. (This is incorrect!)
> * In `before.ttl`, both instances in the triple data are (correctly)
> classified as `ic:InformPurpose` and `ic:Purpose`, but in
> `after.ttl`, one of the resources is not classified as `ic:Purpose`
> anymore (even though the model hasn't changed; only SELECT queries
> were fired).
>
> Note that this behaviour does not occur when we use Jena 4.1.0.
>
> Are we missing something, or is this indeed a bug?
>
> Best,
> Han Kruiger
> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
>