[rules-users] StatefulKnowledgeSession leaves threads running

Edson Tirelli tirelli at post.com
Fri Jul 17 11:09:41 EDT 2009


   Rafael,

   It is the JDK class:

Class ScheduledThreadPoolExecutor
  Check the API for methods shutdown() and shutdownNow(). I am also looking
at the JDK source code. It seems safe in our case to change the call to
shutdownNow() instead of the previous call to shutdown(). The shutdown is
called on session dispose() only and as so it is an irreversible operation
anyway.

  I am just double checking, but I think there is no choice. Brian Goetz's
Java Concurrency in Practice also states that the jdk blocking operations
may or may not be canceled gracefully (case-by-case) on chapter 7.

  Give me another hour to make sure everything is ok and I will commit a
fix.

https://jira.jboss.org/jira/browse/JBRULES-2211

   []s
   Edson




2009/7/17 Rafael Ribeiro <rafaelri at gmail.com>

> Edson:
>
>  Is it a code change inside Drools or is there any other shutdown method
> that I may call ?
>
> Mark:
>
>  I completely agree with this future change, it makes much sense in an
> AppServer environment where we shouldn't be handling thread creation and
> disposal by ourselves.
>
> regards,
> Rafael
>
>
> 2009/7/17 Edson Tirelli <tirelli at post.com>
>
>
>>     The problem here is a different one. The engine is calling shutdown()
>> on a thread pool and even without any task being executed, the thread is
>> blocked in an internal JDK queue waiting for the timeout. I replaced the
>> call by shutdownNow(), forcing the jdk to signal an interrupt to the thread
>> and this seemed to work. I am investigating side effects of this procedure
>> right now.
>>
>>     []s
>>     Edson
>>
>>
>> 2009/7/16 Mark Proctor <mproctor at codehaus.org>
>>
>> Rafael Ribeiro wrote:
>>> > Hi all,
>>> >
>>> >  I've downloaded Drools fusion sample and started to make some changes
>>> to
>>> > the code (first of all wipe out the UI so I can test it easier).
>>> >  I tried to get to a minimal set so I can run a console main class and
>>> see
>>> > what happens but I am facing a strange behaviour.
>>> >  As soon as I start pushing events into the WorkingMemoryEntryPoint
>>> > ("StockTick stream") a Thread - not daemonized since it blocks shutdown
>>> from
>>> > ending - is spawned and this prevents my JVM from shutting down
>>> (obviously
>>> > if I call System.exit(0) it will but I am avoiding this).
>>> >  I've tried both to halt and dispose the session that this entry point
>>> > belongs but with no success. Does anyone know how could I get rid of
>>> this
>>> > thread?
>>> >
>>> Drools is starting up threads in a number of places now - using "new
>>> Thread()". I think the plan is to change this to an interface call that
>>> allows pluggable implementations. So that the user can decide how
>>> threads are executed and stopped.
>>>
>>> Mark
>>> > best regards,
>>> >
>>>
>>>
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>
>>
>>
>> --
>>  Edson Tirelli
>>  JBoss Drools Core Development
>>  JBoss by Red Hat @ www.jboss.com
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>


-- 
 Edson Tirelli
 JBoss Drools Core Development
 JBoss by Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20090717/fea225e8/attachment.html 


More information about the rules-users mailing list