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 <[email protected]> Sent: donderdag 14 oktober 2021 12:36 To: [email protected] 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. >>>
