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 <[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/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.
