Andy Seaborne

Hi @SamuelBoerlin, Thanks for the report. Do you have the to show which operations were happening/had just happened on the server just before the problem started? The stacktrace looks more...

Hi @SamuelBoerlin, (unrelated - you are running on Java23?) I was hoping to see active operations (maybe the last 3?) just before `23:00:00.830`, `23:00:03.459` and `23:00:53.421`. It's a bit difficult...

There's a development build at https://repository.apache.org/content/groups/snapshots/org/apache/jena/apache-jena-fuseki/ This is not a release. It is no more than a build of the current codebase. > They're probably not very useful as they...

Jena 5.2.0 has the change to not print the NPE stacktrace. Thete may be a second stacktrace (whiuch mnight even have some usefule information) but probably only once.

@SamuelBoerlin The logs only need to be at level INFO and above. There are two queries before the NPE (69964) which are of the same form as 64 but then...

Hi @SamuelBoerlin - the info logs are much easier for extracting the server level information - thanks. Did you mange to run with Jena 5.2.0? It protects against the NPE...

Hi @SamuelBoerlin, Thanks for investigating. In the 5.1.0 logs, the error is on a read operation and the exception is happening after the query response has been sent so I...

I haven't been able to recreate this with current Jena. PR #2829 tidies up an inconsistent code pattern in jena-text but even manually single-stepping multiple threads through the execution didn't...

@SamuelBoerlin -- the data will be intact. The problem is on a read-path, not the update path. Knowing your client side code is calling sequentially is useful to know. It...

Thanks for the update.