Yes, Jena bug, possibly related to the -1 length.
Recorded as:
https://issues.apache.org/jira/browse/JENA-1776
-1 is because Jena streams the content for a GSP PUT operation. It does
not know the length at the start of request. To get the length you have
to produce the content then send the request - which is not streaming.
A "feature" of HTTP.
So I'm guessing that the connection is not handled like the default (no
auth) version in some way but I don't know why.
RDFConnectionRemote has a builder and connectPW is just this:
public static RDFConnection connectPW(String URL, String user, String
password) {
BasicCredentialsProvider credsProvider =
new BasicCredentialsProvider();
Credentials credentials =
new UsernamePasswordCredentials(user, password);
credsProvider.setCredentials(AuthScope.ANY, credentials);
HttpClient client = HttpClients.custom()
.setDefaultCredentialsProvider(credsProvider)
.build();
return RDFConnectionRemote.create()
.destination(URL)
.httpClient(client)
.build();
}
so it is a matter for setting up the HttpClient correctly (setting it up
so it is closed after each use? This is the compromise HTTP requires -
stream once, or buffer and send length with connection reuse).
The normal, no auth default is
HttpOp.createPoolingHttpClientBuilder
Andy
FYI: I'm away, no development machine (if I even have internet access,
and that's not certain), for a week or so.
On 31/10/2019 14:45, Sebastian Trueg wrote:
So... a Jena bug then? Do you have an idea if there is something I can
configure in the HttpClient as a workaround?
On 31.10.19 15:18, Andy Seaborne wrote:
I can make it happen sporadically using Fuseki main (so no shiro, not a
webapp environment). It happens maybe one in four test runs.
It looks like a client-side problem - it creates the HTTP connection
each time and maybe something is cached in HttpClient. A hash-map-ism
would explain the "sporadically". If so, the # triples effect maybe
causing the timing to get changed a little.
Andy
On 31/10/2019 13:27, Sebastian Trueg wrote:
Interestingly it does not. Only going down to a really small number of
triples does work.
And to make sure I did implement manual HTTP DELETE+PUT via OkHttp which
works without problems on the same Fuseki instance.
Regards,
Sebastian
On 31.10.19 14:14, Andy Seaborne wrote:
Thanks.
Presumably it works if you create the RDFConnection once and reuse the
java object?
Andy
On 31/10/2019 12:10, Sebastian Trueg wrote:
Hi Andy,
- Fuseki started via "fuseki-server".
- shiro config attached
- "pdm-data-model" dataset created via attached config
- Simple test app attached which takes the fuseki dataset url as
parameter.
Hope this helps.
Regards,
Sebastian
On 31.10.19 11:55, Andy Seaborne wrote:
Sebastian,
Do you have a complete, minimal example, including the Fuseki setup
for
the user/password. Which Fuseki variant? war? full-jar? main?
Andy
PS Don't forget teh javadoc on connectPW : it's "basic auth"
On 31/10/2019 10:30, Sebastian Trueg wrote:
Hi everyone,
trying to use RDFConnection with Jena 3.13.1 to put a Model into a
remote Fuseki instance I encountered very strange behavior. First
off,
let me show my very simple code:
try(RDFConnection conn
= RDFConnectionFactory.connectPW(datasetUrl, "admin",
"admin")) {
conn.put(graphUri, model);
}
This works fine on its own and for very small models in general.
But as
soon as I repeat the exact same snippet of code, ie. run the same try
block twice I get a SocketException (Broken pipe) on the first
call to
RDFConnection::put.
So, to sum up:
- Single put works fine.
- A subsequent call to put will result in the first one already
throwing
an exception!
- Using a model with less than 100 triples results in both put
operations to succeed.
- In all this the Fuseki instance keeps on working.
Any ideas?
Regards,
Sebastian
