Re: Thread pool not shutting down properly
Sorry, version is 2.11.1
Yes, it happens every time. We shut down using the standard ./shutdown.sh
script in tomcat/bin. It's a bit hard to create a reproducible on it but I
could give it a shot to see if I can prove that the thread pool does block
even after expiry. You're right that it's not a daemon.
Interface-izing would help = very good thing imho.
On Tue, Nov 25, 2014 at 6:02 AM, Andy Seaborne wrote:
> Stephen,
>
> (version?)
> How are you shutting down tomcat?
>
> It could be that the problem is that the thread is not a daemon thread
> which can block the JVM exiting when the main thread returns.
>
> Does this happen every time because I through that when all timers
> expired, the ScheduledThreadPoolExecutor did not block JVM exiting (but I
> have not tried in anger).
>
>
> Unrelated question inline:
>
> On 25/11/14 02:40, Stephen Owens wrote:
>
>> Folks,
>>
>> I'm seeing a problem with a thread pool blocking shutdown of Tomcat. The
>> pool seems to be created by the AlarmClock class in Jena which I think is
>> being instantiated from QueryExecutionBase. The problem only seems to
>> occur
>> if I execute a SPARQL query with a timeout set like so:
>>
>>QueryExecution queryExec = QueryExecutionFactory.create(query, model);
>>queryExec.setTimeout(queryTimeout);
>>
>> I have a work around for the behaviour by manually releasing the clock
>> using a hack that causes grown developers to cry. In a class invoked at
>> application shutdown I do this:
>>
>> private final AlarmClock defaultAlarmClock = AlarmClock.get();
>> public void shutdown()
>> {
>> defaultAlarmClock.release();
>> }
>>
>> I'm assuming that this is not actually required and that I'm doing
>> something wrong executing the SPARQL or terminating the query. Any hints
>> are most welcome. Here's the full version of the SPARQL execution code in
>> case it is of use in helping locate the issue:
>>
>
>
>
> Set results = new HashSet();
>>
>
> results.add(new AttachedTripleImpl(statement));
>>
>
> So AttachedTripleImpl extends Triple?
>
> We're discussing interface-izing triples for Jena3. Would that
> help/hinder you?
>
> Andy
>
>
>
--
Regards,
*Stephen Owens*
CTO, ThoughtWire
t 647.351.9473 ext.104 I m 416.697.3466
Re: Thread pool not shutting down properly
Stephen,
(version?)
How are you shutting down tomcat?
It could be that the problem is that the thread is not a daemon thread
which can block the JVM exiting when the main thread returns.
Does this happen every time because I through that when all timers
expired, the ScheduledThreadPoolExecutor did not block JVM exiting (but
I have not tried in anger).
Unrelated question inline:
On 25/11/14 02:40, Stephen Owens wrote:
Folks,
I'm seeing a problem with a thread pool blocking shutdown of Tomcat. The
pool seems to be created by the AlarmClock class in Jena which I think is
being instantiated from QueryExecutionBase. The problem only seems to occur
if I execute a SPARQL query with a timeout set like so:
QueryExecution queryExec = QueryExecutionFactory.create(query, model);
queryExec.setTimeout(queryTimeout);
I have a work around for the behaviour by manually releasing the clock
using a hack that causes grown developers to cry. In a class invoked at
application shutdown I do this:
private final AlarmClock defaultAlarmClock = AlarmClock.get();
public void shutdown()
{
defaultAlarmClock.release();
}
I'm assuming that this is not actually required and that I'm doing
something wrong executing the SPARQL or terminating the query. Any hints
are most welcome. Here's the full version of the SPARQL execution code in
case it is of use in helping locate the issue:
Set results = new HashSet();
results.add(new AttachedTripleImpl(statement));
So AttachedTripleImpl extends Triple?
We're discussing interface-izing triples for Jena3. Would that
help/hinder you?
Andy
Thread pool not shutting down properly
Folks,
I'm seeing a problem with a thread pool blocking shutdown of Tomcat. The
pool seems to be created by the AlarmClock class in Jena which I think is
being instantiated from QueryExecutionBase. The problem only seems to occur
if I execute a SPARQL query with a timeout set like so:
QueryExecution queryExec = QueryExecutionFactory.create(query, model);
queryExec.setTimeout(queryTimeout);
I have a work around for the behaviour by manually releasing the clock
using a hack that causes grown developers to cry. In a class invoked at
application shutdown I do this:
private final AlarmClock defaultAlarmClock = AlarmClock.get();
public void shutdown()
{
defaultAlarmClock.release();
}
I'm assuming that this is not actually required and that I'm doing
something wrong executing the SPARQL or terminating the query. Any hints
are most welcome. Here's the full version of the SPARQL execution code in
case it is of use in helping locate the issue:
public Set findBySparql( Query query)
{
Set results = new HashSet();
try {
model.enterCriticalSection(Lock.READ);
QueryExecution queryExec = QueryExecutionFactory.create(query, model);
queryExec.setTimeout(queryTimeout);
try {
Model resultModel = queryExec.execConstruct();
StmtIterator statements = resultModel.listStatements();
try {
while ( statements.hasNext()) {
Statement statement = statements.next();
results.add(new AttachedTripleImpl(statement));
}
}
finally {
statements.close();
}
}
finally {
queryExec.close();
}
}
finally {
model.leaveCriticalSection();
}
return results;
}
--
Regards,
*Stephen Owens*
CTO, ThoughtWire
t 647.351.9473 ext.104 I m 416.697.3466
