Rajiv,
I have failed to reproduce this. I ran a Fuseki server and sent 1000's
of ASK queries to it. No threads were created.
I used quite simple ASK queries - maybe there is complexity in queryStr?
The results of an ASK query are about 400 bytes on the wire, including
HTTP header - that fits in an IP packet and so in TCP buffering. The
server will respond to a request, finish the HTTP response and send it
without any way for the client to lead the connection hanging around.
But your server is under a different load so I would speculate that the
change you made perturbed the situation but is not the root cause. If
so, problems may arise later.
Could you please point a profiler at the server and report what the
additional threads are doing? jvisualvm will do this to a running
server (thread dump under the treads section) as will YourKit, which is
easier to read afterwards.
Andy
On 12/12/13 18:57, Andy Seaborne wrote:
On 12/12/13 18:41, Chaudhuri, Rajiv wrote:
QueryExecution qexec =
QueryExecutionFactory.sparqlService(queryServiceIRI, queryStr);
try {
boolean result = qexec.execAsk();
if (! result) {
}
} finally {
qexec.close();
}
Thanks.
Recorded as JENA-610
https://issues.apache.org/jira/browse/JENA-610
Andy
On Thu, Dec 12, 2013 at 1:36 PM, Andy Seaborne <[email protected]> wrote:
On 12/12/13 18:15, Chaudhuri, Rajiv wrote:
The issue got resolved. execAsk does not release the thread even if we
close the query execution; as an alternative we have used execSelect
and
check whether data exist or not.
Then that's a bug we need to fix.
Which format are you using in the request to the server?
Andy
