Okay, both are good hints!
thanks for the feedback!
Met Vriendelijke Groet / With Kind Regards
Bart van Leeuwen
twitter: @semanticfire
tel. +31(0)6-53182997
Netage B.V.
http://netage.nl
Esdoornstraat 3
3461ER Linschoten
The Netherlands
From: Andy Seaborne
To: users@jena.apache.org
Da
Andreas,
I'll take a look - one of the problems of running that service has been
(unsurprisingly) it getting trashed. A public endpoint reading files
from the web is a DOS vector. People trying to load DBpedia etc. (no,
that does not work!).
(The VM it runs on is also quite locked down whic
On 13/02/2019 11:34, Martynas Jusevičius wrote:
Are you closing the QueryExecution objects?
That is certainly something to look for. The fact it is ~6 connections
suggest that as well.
There's help for this - QueryExecution is a Java AutoCloseable so you
can write:
try(QueryExecution
Are you closing the QueryExecution objects?
I've experienced similar stuff with Apache HTTP Client that would reach the
limit of connections per route and then would just hang without any error
messages.
On Wed, Feb 13, 2019 at 10:04 AM Bart van Leeuwen <
bart_van_leeu...@netage.nl> wrote:
> So
Hi Andy,
I am running Fuseki as a service (i.e. with "fuseki start"), without any
modifications to the configuration. I have added a dataset with multiple named
graphs through the web interface, and I tried running the queries through the
web interface as well, although I am later planning to
Fuseki does support loading FROM URLs from the web in the "main" version
of Fuseki. If the service is backed by a dataset it will use the graphs
from the dataset but there is the "general" query service as well.
It is --general in Fuseki.main and that is what
http://www.sparql.org/sparql.htm
So in the mean time I've been trying to understand the issue a bit better.
>From 3.1.0 to 3.2.0 the most notable difference is the HTTPClient package
which introduces the PoolingHttpClientConnectionManager
( this is visibile in the stacktrace )
Since we run in Tomee ( Tomcat with EJB ) this is t