Clojure agent thread pool improvements

[Alex Miller]

I tangled with Clojure agents recently and while agents rock, I had
some unpleasant operational experiences that led me to dig in a bit
deeper. Due to the length, I dropped this in a blog entry that details
some issues and possible solutions:

http://tech.puredanger.com/2010/06/08/clojure-agent-thread-pools/

In very brief summary:
1) Agent thread pools should use named threads - patch for this here:
http://puredanger.com/techfiles/agent-name.diff. I'm happy to log a
ticket and the patch if this seems generally desirable.

2) Agent thread pools use non-daemon threads that can block jvm exit
(or require use of (shutdown-agents)). To me this feels broken. Some
possible solutions:
a) always use daemons and force users that want the jvm-keepalive
behavior to use a keepalive thread
b) always use daemon threads but allow new :sendPool
and :sendOffPool options on agents to pass a custom ExecutorService
that can do whatever you want
c) create new variants of send or use a global *foo* to choose
whether to use daemon or non-daemon
d) ???

3) (shutdown-agents) waits for existing actions to complete - suggests
to mean a complementary (kill-agents) that calls shutdownNow() on the
executor service (instead of shutdown()).

4) (shutdown-agents) is non-reversible - I dislike having magic
functions that irreversibly break parts of the Clojure runtime so
would like removing the need for this (see #2) or making it reversible
(although the concurrency issues are tricky and maybe not worth
doing).

Thanks for your consideration.

Alex Miller

[Shawn Hoover]

There's a ticket for this, by the way: http://www.assembla.com/spaces/clojure/tickets/124

--
You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
To post to this group, send email to cloju...@googlegroups.com.
To unsubscribe from this group, send email to clojure-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/clojure-dev?hl=en.

[Shawn Hoover]

I'd like to suggest daemon threads as Alex suggested. Users who want to block can use a keepalive thread or block on the agents (await) or futures (deref) that need to stay alive. And then shutdown-agents can go away.

[Chas Emerick]

This issue has been kicking around for a long time, as you can tell from the ticket.

I am fully behind Alex's 2a, as I was when I opened the ticket.

My understanding is that assigning agents to given threadpools/executors is solidly on the table for addition post-1.2 -- this would encompass something like 2b (and is orthogonal to whether the default pools use daemon threads as in 2a).

Presumably, 2a would eliminate the need for shutdown-agents, and therefore points 3 and 4. :-)

- Chas

[Alex Miller]

Thanks Shawn and Chas.  I added some comments to ticket #124 and I would definitely like to see those changes (post 1.2).  

I have also filed ticket #378 regarding the agent thread pool thread names.  When I first ran into the "hanging JVM" problem it was quickly clear to me that those threads were not exiting, but much more difficult to tell where the threads were coming from (as their stack traces in a thread dump just show typical thread start, not who started the ThreadPool in the first place).  I tracked it down via a debugger and profiler but having named threads would have given me a very strong pointer in diagnosing the problem.  I believe the names would be similarly useful if I was trying to diagnose a performance issue that involved agents.

Alex

[Rich Hickey]

These are all good and welcome ideas. Post 1.2 ...

Thanks,

Rich

On Jun 9, 11:05 am, Alex Miller <alexdmil...@yahoo.com> wrote:
> Thanks Shawn and Chas.  I added some comments to ticket #124 and I would definitely like to see those changes (post 1.2).  
>
> I have also filed ticket #378 regarding the agent thread pool thread names.  When I first ran into the "hanging JVM" problem it was quickly clear to me that those threads were not exiting, but much more difficult to tell where the threads were coming from (as their stack traces in a thread dump just show typical thread start, not who started the ThreadPool in the first place).  I tracked it down via a debugger and profiler but having named threads would have given me a very strong pointer in diagnosing the problem.  I believe the names would be similarly useful if I was trying to diagnose a performance issue that involved agents.
>
> Alex
>
>
>
>
>
>
>
> >From: Chas Emerick <cemer...@snowtide.com>
> >To: cloju...@googlegroups.com
> >Sent: Wed, June 9, 2010 8:15:05 AM
> >Subject: Re: Clojure agent thread pool improvements
>
> >This issue has been kicking around for a long time, as you can tell from the ticket.
>
> >I am fully behind Alex's 2a, as I was when I opened the ticket.
>
> >My understanding is that assigning agents to given threadpools/executors is solidly on the table for addition post-1.2 -- this would encompass something like 2b (and is orthogonal to whether the default pools use daemon threads as in 2a).
>
> >Presumably, 2a would eliminate the need for shutdown-agents, and therefore points 3 and 4. :-)
>
> >- Chas
>
> >On Jun 9, 2010, at 8:58 AM, Shawn Hoover wrote:
>
> >There's a ticket for this, by the way:http://www.assembla.com/spaces/clojure/tickets/124
>

> >>>For more options, visit this group athttp://groups.google.com/group/clojure-dev?hl=en.

>
> --
> >>You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
> >>To post to this group, send email to cloju...@googlegroups.com.
> >>To unsubscribe from this group, send email to clojure-dev...@googlegroups.com.

> >>For more options, visit this group athttp://groups.google.com/group/clojure-dev?hl=en.