Open SamuelBoerlin opened 1 month ago
SamuelBoerlin
commented
1 month ago We're considering downgrading to 5.0.0 for the time being to avoid this. Can we do this by simply going back to 5.0.0 without a recreating the data or would we run into issues if we do that? Alternatively we could dump the data, downgrade and restore; but the former would of course be simpler if that works.
afs
commented
1 month ago 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 like the effect of something that happened in a previous operation.
Would you be able to try a development build (not for production). Jena 5.2.0 is approaching and I recall a related report with a different stacktrace but in the area.
re: revert to 5.0.0 -- the database has not change format. The version of Lucene may be different in the minor patch version so should work as well.
BTW:
the rdfs:subClassOf triples can be removed as can the ja:loadClass - they look like they are from quite an old setup.
SamuelBoerlin
commented
1 month ago Hi @afs
Thanks for your help!
The logs are very large so it's a bit tricky to pinpoint what exactly is happening before the error. I'll see if I can get a minimal reproduction going so I can give you some better info including queries.
For now I can give you these logs here. They're probably not very useful as they don't have INFO level logs, but otherwise it's complete:
2024-10-01 08:48:47.032 │ Apache Jena Fuseki 5.1.0
2024-10-01 08:48:48.087 │ WARNING: A restricted method in java.lang.foreign.Linker has been called
2024-10-01 08:48:48.088 │ WARNING: java.lang.foreign.Linker::downcallHandle has been called by the unnamed module
2024-10-01 08:48:48.088 │ WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for this module
2024-10-01 08:48:48.088 │
2024-10-01 08:48:48.199 │ Oct 01, 2024 6:48:48 AM org.apache.lucene.store.MemorySegmentIndexInputProvider <init>
2024-10-01 08:48:48.199 │ INFO: Using MemorySegmentIndexInput and native madvise support with Java 21 or later; to disable start with -Dorg.apache.lucene.store.MMapDirectory.enableMemorySegments=false
2024-10-01 08:48:48.294 │ Oct 01, 2024 6:48:48 AM org.apache.lucene.internal.vectorization.VectorizationProvider lookup
2024-10-01 08:48:48.294 │ WARNING: Java vector incubator module is not readable. For optimal vector performance, pass '--add-modules jdk.incubator.vector' to enable Vector API.
2024-10-01 08:48:48.421 │ Configuration file: /fuseki/config.ttl
2024-10-01 08:48:48.422 │ Path = /dsp-repo
2024-10-01 08:48:48.425 │ Memory: 1.0 GiB
2024-10-01 08:48:48.425 │ Java: 21.0.4
2024-10-01 08:48:48.426 │ OS: Linux 5.4.0-196-generic amd64
2024-10-01 08:48:48.426 │ PID: 7
2024-10-01 08:48:48.457 │ Started 2024/10/01 06:48:48 UTC on port 3030
2024-10-01 23:00:00.830 │ Task : 1 : Compact
2024-10-01 23:00:00.839 │ [Task 1] starts : Compact
2024-10-01 23:00:03.459 │ [Task 1] finishes : Compact
2024-10-01 23:00:53.421 │ [66393] end called - Not in an action
2024-10-01 23:00:53.429 │
[66393] RC = 500 : Cannot invoke "org.apache.jena.query.ReadWrite.ordinal()" because the return value of "org.apache.jena.sparql.core.Transactional.transactionMode()" is null
java.lang.NullPointerException: Cannot invoke "org.apache.jena.query.ReadWrite.ordinal()" because the return value of "org.apache.jena.sparql.core.Transactional.transactionMode()" is null
at org.apache.jena.fuseki.servlets.HttpAction.endInternal(HttpAction.java:333)
at org.apache.jena.fuseki.servlets.HttpAction.endRead(HttpAction.java:400)
at org.apache.jena.fuseki.servlets.SPARQLQueryProcessor.execute(SPARQLQueryProcessor.java:293)
at org.apache.jena.fuseki.servlets.SPARQLQueryProcessor.executeWithParameter(SPARQLQueryProcessor.java:225)
at org.apache.jena.fuseki.servlets.SPARQLQueryProcessor.execute(SPARQLQueryProcessor.java:210)
at org.apache.jena.fuseki.servlets.ActionService.executeLifecycle(ActionService.java:58)
at org.apache.jena.fuseki.servlets.SPARQLQueryProcessor.execPost(SPARQLQueryProcessor.java:85)
at org.apache.jena.fuseki.servlets.ActionProcessor.process(ActionProcessor.java:34)
at org.apache.jena.fuseki.servlets.ActionBase.process(ActionBase.java:54)
at org.apache.jena.fuseki.servlets.ActionExecLib.execActionSub(ActionExecLib.java:127)
at org.apache.jena.fuseki.servlets.ActionExecLib.execAction(ActionExecLib.java:101)
at org.apache.jena.fuseki.server.Dispatcher.dispatchAction(Dispatcher.java:240)
at org.apache.jena.fuseki.server.Dispatcher.process(Dispatcher.java:230)
at org.apache.jena.fuseki.server.Dispatcher.dispatch(Dispatcher.java:148)
at org.apache.jena.fuseki.servlets.FusekiFilter.doFilter(FusekiFilter.java:49)
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205)
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1586)
at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:65)
at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:109)
at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:138)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:156)
at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:70)
at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:109)
at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:138)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:156)
at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:70)
at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:109)
at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:138)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:156)
at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:70)
at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:463)
at org.apache.shiro.web.servlet.AbstractShiroFilter.lambda$doFilterInternal$0(AbstractShiroFilter.java:378)
at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:91)
at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:84)
at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:389)
at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:376)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:156)
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205)
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1586)
at org.apache.jena.fuseki.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:351)
at org.apache.jena.fuseki.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:304)
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:208)
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1586)
at org.eclipse.jetty.ee10.servlet.ServletHandler$MappedServlet.handle(ServletHandler.java:1547)
at org.eclipse.jetty.ee10.servlet.ServletChannel.dispatch(ServletChannel.java:824)
at org.eclipse.jetty.ee10.servlet.ServletChannel.handle(ServletChannel.java:436)
at org.eclipse.jetty.ee10.servlet.ServletHandler.handle(ServletHandler.java:464)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:575)
at org.eclipse.jetty.ee10.servlet.SessionHandler.handle(SessionHandler.java:703)
at org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:858)
at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:597)
at org.eclipse.jetty.server.Server.handle(Server.java:181)
at org.eclipse.jetty.server.internal.HttpChannelState$HandlerInvoker.run(HttpChannelState.java:648)
at org.eclipse.jetty.server.internal.HttpConnection.onFillable(HttpConnection.java:403)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:322)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:99)
at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:53)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:478)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:441)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:293)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.run(AdaptiveExecutionStrategy.java:201)
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:311)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:979)
2024-10-01 23:00:53.533 │ [66395] end called - Not in an action
2024-10-01 23:00:53.535 │
[66395] RC = 500 : Cannot invoke "org.apache.jena.query.ReadWrite.ordinal()" because the return value of "org.apache.jena.sparql.core.Transactional.transactionMode()" is null
java.lang.NullPointerException: Cannot invoke "org.apache.jena.query.ReadWrite.ordinal()" because the return value of "org.apache.jena.sparql.core.Transactional.transactionMode()" is null
at org.apache.jena.fuseki.servlets.HttpAction.endInternal(HttpAction.java:333)
at org.apache.jena.fuseki.servlets.HttpAction.endRead(HttpAction.java:400)
at org.apache.jena.fuseki.servlets.SPARQLQueryProcessor.execute(SPARQLQueryProcessor.java:293)
at org.apache.jena.fuseki.servlets.SPARQLQueryProcessor.executeWithParameter(SPARQLQueryProcessor.java:225)
at org.apache.jena.fuseki.servlets.SPARQLQueryProcessor.execute(SPARQLQueryProcessor.java:210)
at org.apache.jena.fuseki.servlets.ActionService.executeLifecycle(ActionService.java:58)
at org.apache.jena.fuseki.servlets.SPARQLQueryProcessor.execPost(SPARQLQueryProcessor.java:85)
at org.apache.jena.fuseki.servlets.ActionProcessor.process(ActionProcessor.java:34)
at org.apache.jena.fuseki.servlets.ActionBase.process(ActionBase.java:54)
at org.apache.jena.fuseki.servlets.ActionExecLib.execActionSub(ActionExecLib.java:127)
at org.apache.jena.fuseki.servlets.ActionExecLib.execAction(ActionExecLib.java:101)
at org.apache.jena.fuseki.server.Dispatcher.dispatchAction(Dispatcher.java:240)
at org.apache.jena.fuseki.server.Dispatcher.process(Dispatcher.java:230)
at org.apache.jena.fuseki.server.Dispatcher.dispatch(Dispatcher.java:148)
at org.apache.jena.fuseki.servlets.FusekiFilter.doFilter(FusekiFilter.java:49)
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205)
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1586)
at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:65)
at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:109)
at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:138)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:156)
at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:70)
at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:109)
at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:138)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:156)
at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:70)
at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:109)
at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:138)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:156)
at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:70)
at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:463)
at org.apache.shiro.web.servlet.AbstractShiroFilter.lambda$doFilterInternal$0(AbstractShiroFilter.java:378)
at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:91)
at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:84)
at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:389)
at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:376)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:156)
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205)
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1586)
at org.apache.jena.fuseki.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:351)
at org.apache.jena.fuseki.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:304)
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:208)
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1586)
at org.eclipse.jetty.ee10.servlet.ServletHandler$MappedServlet.handle(ServletHandler.java:1547)
at org.eclipse.jetty.ee10.servlet.ServletChannel.dispatch(ServletChannel.java:824)
at org.eclipse.jetty.ee10.servlet.ServletChannel.handle(ServletChannel.java:436)
at org.eclipse.jetty.ee10.servlet.ServletHandler.handle(ServletHandler.java:464)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:575)
at org.eclipse.jetty.ee10.servlet.SessionHandler.handle(SessionHandler.java:703)
at org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:858)
at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:597)
at org.eclipse.jetty.server.Server.handle(Server.java:181)
at org.eclipse.jetty.server.internal.HttpChannelState$HandlerInvoker.run(HttpChannelState.java:648)
at org.eclipse.jetty.server.internal.HttpConnection.onFillable(HttpConnection.java:403)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:322)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:99)
at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:53)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:478)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:441)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:293)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.run(AdaptiveExecutionStrategy.java:201)
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:311)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:979)
and so on...There are no other errors or warnings before the end called - Not in an action and subsequent NPE.
Yes, sure. I can give the dev build a try. Where can I find it?
Aha, thanks for that tip with removing rdfs:subClassOf and ja:loadClass!
afs
commented
1 month ago 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 to recreate.
2024-10-01 08:48:48.457 │ Started 2024/10/01 06:48:48 UTC on port 3030
2024-10-01 23:00:00.830 │ Task : 1 : Compact
2024-10-01 23:00:00.839 │ [Task 1] starts : Compact
2024-10-01 23:00:03.459 │ [Task 1] finishes : Compact
2024-10-01 23:00:53.421 │ [66393] end called - Not in an actionWhat I think is happening is that an operation is crashing and not clearing up properly. Something would normally be logged. The text index may be a factor - or it may not - I can't tell. Compact is also a suspect although it should log messages on any problem.
"end called - Not in an action" is a warning message put out when the system detects a problem - it's not the problem itself. It was added in 5.1.0 so maybe there was something already wrong but silent (!!).
The stacktrace NPE is not the error - it's collateral damage during Fuseki action clean up. PR #2760 traps the condition that causes it; that's not a fix to the root cause.
afs
commented
1 month ago 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 don't have INFO level logs, but otherwise it's complete:
I can't think of a way to reproduce this without some more information I'm afraid. Ideally a a sequence of operations from empty.The INFO level logs for the last few operations recently completed or or in-progress might help.
SamuelBoerlin
commented
1 month ago Hi again, I now have some logs I can share:
I've included a couple of requests before the NPE.
This time it happened without any prior compaction, so I guess that rules out compaction being involved in this issue.
(unrelated - you are running on Java23?)
No, currently Java 21.
afs
commented
1 month ago 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.
afs
commented
1 month ago @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 there is a big gap back to with some request at 69908 and before. The timestamp always 16:45:16. I don't see any updates.
SamuelBoerlin
commented
1 month ago Hello @afs
Sorry about that.
I've reproduced the issue again on 5.1.0, this time with the default logging settings, i.e. INFO and above. fuseki_npe_5_1_0.txt
I'm also trying to reproduce it with the new 5.2.0 version now. I'll let you know once I have the results.
afs
commented
3 weeks ago 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 and may run into a problem closer to the root cause.
SamuelBoerlin
commented
2 weeks ago Hi @afs
I finally managed to run it with 5.2.0. Unfortunately it took a while due to some other unrelated issues.
So, as expected, the NPE no longer occurs in 5.2.0. There are no exceptions, warning or error logs at all and it seemingly works just fine.
However, I'm not sure whether the underlying problem is actually fixed now or perhaps still exists and is now just silently ignored.
Do you think it'd make sense to add a WARNING level log line here and try again?
And do you reckon there's a chance that data is not persisted properly when above case occurs? I don't yet have a simple way of verifying that the data persisted in the DB is actually fully correct, but I suppose I could at least compare the number of persisted triples in 5.0.0 vs. 5.2.0 for now.
afs
commented
2 weeks ago 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 don't think that 5.2.0 would be causing any visible dropped queries in the client. Is this the case?
In the log sample from 5.1.0, there isn't any overlapping operations, query or update. The log shows that all queries and updates execute in sequence with no overlaps of operations. The last update was 15 HTTP requests back.
Is the client software making calls from just one client thread/process or from several? What library is the client software running to send SPARQL requests?
As updates are showing as happening, there isn't some old update starting before the log sample still hanging around.
So I don't think data has been dropped.
If that analysis is right, It is beginning to look like a thread-variable-consistency problem with the read-path. Jetty is probably using multiple threads causing true parallelism in the system, which is fine. In 5.2.0, the internal state is likely to be self-correcting, overwritten by a later read operation but that is speculation on my part.
I may be able to reproduce something now. Caveat - if the above is the cause, it's all about exact timings and is going to be sensitive to the hardware and environment.
If you have cleaned up the config.ttl file, could you put the current one you are using on the issue so I have exactly the same as you?
afs
commented
2 weeks ago 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 show the problem.
SamuelBoerlin
commented
1 week ago Hi @afs
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 don't think that 5.2.0 would be causing any visible dropped queries in the client. Is this the case?
No, I haven't observed any dropped queries. I was just curious about possible implications if this error were "silently ignored" now with the safeguard (https://github.com/apache/jena/commit/192f02e31f28b234e6944f323b697dce8f9cb929) introduced in 5.2.0. Perhaps the underlying problem (if there is one) is even completely solved in 5.2.0 and the safeguard isn't even being hit anymore, but I don't have a way of knowing that without some extra logging or breakpoint there. So, just to be clear, in 5.2.0 it seems to work fine without error and, as far as I can tell from looking at it superficially, the data is also OK.
Is the client software making calls from just one client thread/process or from several?
All the calls/requests are done sequentially.
What library is the client software running to send SPARQL requests?
We're using our own tooling for this (https://github.com/dasch-swiss/dsp-api, https://github.com/dasch-swiss/dsp-tools). The SPARQL requests are done as HTTP GET/POST requests (e.g. https://github.com/dasch-swiss/dsp-api/blob/main/webapi/src/main/scala/org/knora/webapi/store/triplestore/impl/TriplestoreServiceLive.scala#L147-L154).
If you have cleaned up the config.ttl file, could you put the current one you are using on the issue so I have exactly the same as you?
I have not yet changed it, so it's still the same as the one I posted initially.
I haven't been able to recreate this with current Jena. PR https://github.com/apache/jena/pull/2829 tidies up an inconsistent code pattern in jena-text but even manually single-stepping multiple threads through the execution didn't show the problem.
Thanks! I'll give it a try and set a breakpoint or add some logging to check whether the safeguard is still being hit.
Unfortunately I won't be able to do any further tests though until probably the beginning of next week.
afs
commented
1 week ago @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 may be the test throwing the exception was wrong. #2829 does make a change in jena-text (in current development builds).
Finishing up transactions is itself idempotent so even if the HttpAction call is calling unnecessarily, it should be harmless. All that happens is the transaction system gets set to the correct cleared-up state.
Version
5.1.0
What happened?
We recently updated Fuseki from 5.0.0 to 5.1.0 and started experiencing a NullPointerException. Once this this exception has occurred once it keeps happening for all subsequent queries until Fuseki is restarted. While in this state Fuseki still successfully responds to
/$/ping, but queries fail.So far this has only happened on servers where we regularly do compaction, so maybe that's related somehow?
We also persistently ran into this exception while trying to do lots of update queries (i.e. several thousands) with intermittent compaction inbetween to keep the DB size down.
There aren't any other errors/warnings before the exception (except for that one
end called - Not in an actionwarning), nor during the compaction.We're running Fuseki 5.1.0 in a docker container based on the eclipse-temurin:21-jre-jammy image.
Configuration:
Relevant output and stacktrace
Are you interested in making a pull request?
None