On 31/05/2022 07:48, Sebastian Trueg wrote:
Hi Andy,
thx for replying
On 30.05.22 17:41, Andy Seaborne wrote:
if I want to drop a rather big graph from my Fuseki instance I often
run into a timeout. I suppose this is caused by the request taking
longer than a few minutes on Fuseki's end.
My problem is that I cannot figure out how to raise the request
timeout for the RdfConnection.delete/put call.
Assuming the current Jena release:
yes.
There is a connect timeout, this is from java.net.http.HttpClient, but
that is only the "connect" phase of HTTP/TCP.
Other than that, I'm not sure what is timing out.
After about how long does this happen?
Is there any intermediary between the client and the fuseki server?
indeed there is an nginx which was part of the problem.
What does the server log say?
What kind is the Fuseki database?
Is the delete done by SPARQL or RDFConnection.delete?
the latter.
But it seems to have been resolved with the connection timeout and the
nginx configuration.
That delete will have a long period of inactivity.
Now, however, some of my updates are too large (again nginx is the
culprit).
is this nginx client_max_body_size setting? And you get a 413 "Request
Entity Too Large"?
But I was wondering if the payload of an RdfConnection.load
count be gzipped to reduce its size?
Sorry, in the "send data" direction, there isn't support for
compression. Compression, a one time compress-send-decompress would
likely be slower.
The lack of upload compression is due to complexity - you don't know the
size for the Content-Length ahead of time, so there are two choices:
locally cache the compression bytes (yuk at scale) or send with no
length, and that means the connection isn't reusable, no HTTP connection
pooling.
The solution is probably to send files with a separate connection. It
isn't done that way at the moment.
Andy
Cheers,
Sebastian
