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 <a...@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.
