Download [#CLJ-124] GC Issue 120: Determine mechanism for

[CLJ-124] GC Issue 120: Determine mechanism for controlling automatic
shutdown of Agents, with a default policy and mechanism for changing that
policy as needed Created: 17/Jun/09 Updated: 23/Aug/14
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Open
Clojure
None
Release 1.5, Release 1.6
Type:
Reporter:
Resolution:
Labels:
Enhancement
Chas Emerick
Unresolved
agents
Attachments:
clj-124-daemonthreads-v1.patch
Code
Vetted
Rich Hickey
Patch:
Approval:
Waiting On:
None
Minor
Alex Miller
13
Priority:
Assignee:
Votes:
clj-124-v1.patch
Description
The original description when this ticket was vetted is below, starting with "Reported by
[email protected], June 01, 2009". This prefix attempts to summarize the issue and discussion.
Description:
Several Clojure functions involving agents and futures, such as future, pmap, clojure.java.shell/sh, and a few
others, create non-daemon threads in the JVM in an ExecutorService called soloExecutor created via
Executors#newCachedThreadPool. The javadocs for this method here
http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Executors.html#newCachedThreadPool%28%29
say "Threads that have not been used for sixty seconds are terminated and removed from the cache." This
causes a 60-second wait after a Clojure program is done before the JVM process exits. Questions about this
confusing behavior come up a couple of times per year on the Clojure Google group. Search for "shutdownagents" to find most of these occurrences, since calling (shutdown-agents) at the end of one's program
typically eliminates this 60-second wait.
Example:
% java -cp clojure.jar clojure.main -e "(println 1)"
1
[ this case exits quickly ]
% java -cp clojure.jar clojure.main -e "(println @(future 1))"
1
[ 60-second pause before process exits, at least on many platforms and JVMs ]
Summary of comments before July 2014:
Most of the comments on this ticket on or before August 23, 2010 were likely spread out in time before being
imported from the older ticket tracking system into JIRA. Most of them refer to an older suggested patch that
is not in JIRA, and compilation problems it had with JDK 1.5, which is no longer supported by Clojure 1.6.0.
I think these comments can be safely ignored now.
Alex Miller blogged about this and related issues here: http://tech.puredanger.com/2010/06/08/clojure-agentthread-pools/
Since then, two of the suggestions Alex raised have been addressed. One by and one by the addition of setagent-send-executor! and similar functions to Clojure 1.5.0:
https://github.com/clojure/clojure/blob/master/changes.md#23-clojurecoreset-agent-send-executor-set-agentsend-off-executor-and-send-via
One remaining issue is the topic of this ticket, which is how best to avoid this 60-second pause.
Approach #1: automatically shut down agents
One method is mentioned in Chas Emerick's original description below, suggested by Rich Hickey, but
perhaps long enough ago he may no longer endorse it: Create a Var *auto-shutdown-agents* that when true
(the default value), clojure.lang.Agent shutdown() is called after the clojure.main entry point. This removes
the surprising wait for common methods of starting Clojure, while allowing expert users to change that value
to false if desired.
Approach #2: create daemon threads by default
Another method mentioned by several people in the comments is to change the threads created in agent
thread pools to daemon threads by default, and perhaps to deprecate shutdown-agents or modify it to be less
dangerous. That approach is discussed a bit more in Alex's blog post linked above, and in a comment from
Alexander Taggart on July 11, 2011 below.
Approach #3:
The only other comment before 2014 that is not elaborated in this summary is shoover's suggestion: There are
already well-defined and intuitive ways to block on agents and futures. Why not deprecate shutdown-agents
and force users to call await and deref if they really want to block? In the pmap situation one would have to
evaluate the pmap form.
Approach #4: Create a cached thread pool with a timeout much lower than 60 seconds
This could be done by using one of the ThreadPoolExecutor constructors with a keepAliveTime parameter of
the desired time.
Patch: clj-124-v1.patch clj-124-daemonthreads-v1.patch
At most one of these patches should be considered, depending upon the desired approach to take.
Patch clj-124-v1.patch implements appproach #1 using *auto-shutdown-agents*. See the Jul 31 2014
comment when this patch was added for some additional details.
Patch clj-124-daemonthreads-v1.patch implements approach #2 and is straightforward.
Reported by [email protected], Jun 01, 2009
There has been intermittent chatter over the past months from a couple of
people on the group (e.g.
http://groups.google.com/group/clojure/browse_thread/thread/409054e3542adc1f)
and in #clojure about some clojure scripts hanging, either for a constant
time (usually reported as a minute or so with no CPU util) or seemingly
forever (or until someone kills the process).
I just hit a similar situation in our compilation process, which invokes
clojure.lang.Compile from ant. The build process for this particular
project had taken 15 second or so, but after adding a couple of pmap calls,
that build time jumped to ~1:15, with roughly zero CPU utilization over the
course of that last minute.
Adding a call to Agent.shutdown() in the finally block in
clojure.lang.Compile/main resolved the problem; a patch including this
change is attached. I wouldn't suspect anyone would have any issues with
such a change.
----In general, it doesn't seem like everyone should keep tripping over this
problem in different directions. It's a very difficult thing to debug if
you're not attuned to how clojure's concurrency primitives work under the
hood, and I would bet that newer users would be particularly affected.
After discussion in #clojure, rhickey suggested adding a
*auto-shutdown-agents* var, which:
- if true when exiting one of the main entry points (clojure.main, or the
legacy script/repl entry points), Agent.shutdown() would be called,
allowing for the clean exit of the application
- would be bound by default to true
- could be easily set to false for anyone with an advanced use-case that
requires agents to remain active after the main thread of the application
exits.
This would obviously not help anyone initializing clojure from a different
entry point, but this may represent the best compromise between
least-surprise and maximal functionality for advanced users.
-----In addition to the above, it perhaps might be worthwhile to change the
keepalive values used to create the Threadpools used by c.l.Actor's
Executors. Currently, Actor uses a default thread pool executor, which
results in a 60s keepalive. Lowering this to something much smaller (1s?
5s?) would additionally minimize the impact of Agent's threadpools on Java
applications that embed clojure directly (and would therefore not benefit
from *auto-shutdown-agents* as currently conceived, leading to puzzling
'hanging' behaviour). I'm not in a position to determine what impact this
would have on performance due to thread churn, but it would at least
minimize what would be perceived as undesirable behaviour by users that are
less familiar with the implementation details of Agent and code that
depends on it.
Comment 1
by [email protected], Jun 01, 2009
Just FYI, I'd be happy to provide patches for either of the suggestions mentioned
above...
Comments
Comment by Assembla Importer [ 24/Aug/10 12:45 AM ]
Converted from http://www.assembla.com/spaces/clojure/tickets/124
Attachments:
compile-agent-shutdown.patch https://www.assembla.com/spaces/clojure/documents/a56S2ow4ur3O2PeJe5afGb/download/a56S2ow4ur3O2Pe
124-compilation.diff https://www.assembla.com/spaces/clojure/documents/aqn0IGxZSr3RUGeJe5aVNr/download/aqn0IGxZSr3RUG
Comment by Assembla Importer [ 24/Aug/10 12:45 AM ]
oranenj said: [file:a56S2ow4ur3O2PeJe5afGb]
Comment by Assembla Importer [ 24/Aug/10 12:45 AM ]
richhickey said: Updating tickets (#8, #19, #30, #31, #126, #17, #42, #47, #50, #61, #64, #69, #71, #77, #79, #84
#89, #96, #99, #103, #107, #112, #113, #114, #115, #118, #119, #121, #122, #124)
Comment by Assembla Importer [ 24/Aug/10 12:45 AM ]
cemerick said: (In [[r:fa3d24973fc415b35ae6ec8d84b61ace76bd4133]]) Add a call to Agent.shutdown() at the e
clojure.lang.Compile/main Refs #124
Signed-off-by: Chouser <[email protected]>
Branch: master
Comment by Assembla Importer [ 24/Aug/10 12:45 AM ]
[email protected] said: I'm closing this ticket to because the attached patch solves a specific problem. I agree t
idea of an auto-shutdown-agents var sounds like a positive compromise. If Rich wants a ticket to track that issu
it'd be best to open a new ticket (and perhaps mention this one there) rather than use this ticket to track further ch
Comment by Assembla Importer [ 24/Aug/10 12:45 AM ]
scgilardi said: With both Java 5 and Java 6 on Mac OS X 10.5 Leopard I'm getting an error when compiling with
change present.
Java 1.5.0_19
Java 1.6.0_13
For example, when building clojure using "ant" from within my clone of the clojure repo:
[java] java.security.AccessControlException: access denied (java.lang.RuntimePermission modifyThread)
[java] at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
[java] at java.security.AccessController.checkPermission(AccessController.java:427)
[java] at java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:894)
[java] at clojure.lang.Agent.shutdown(Agent.java:34)
[java] at clojure.lang.Compile.main(Compile.java:71)
I reproduced this on two Mac OS X 10.5 machines. I'm not aware of having any enhanced security policies along
lines on my machines. The compile goes fine for me with Java 1.6.0_0 on an Ubuntu box.
Comment by Assembla Importer [ 24/Aug/10 12:45 AM ]
[email protected] said: I had only tested it on my ubuntu box – looks like that was openjdk 1.6.0_0. I'll test aga
sun-java5 and sun-java6.
Comment by Assembla Importer [ 24/Aug/10 12:45 AM ]
[email protected] said: 1.6.0_13 worked fine for me on ubuntu, but 1.5.0_18 generated an the exception Steve
Any suggestions? Should this patch be backed out until someone has a fix?
Comment by Assembla Importer [ 24/Aug/10 12:45 AM ]
achimpassen said: [file:aqn0IGxZSr3RUGeJe5aVNr]
Comment by Assembla Importer [ 24/Aug/10 12:45 AM ]
[email protected] said: With Achim's patch, clojure compiles for me on ubuntu using java 1.5.0_18 from sun,
works on 1.6.0_13 sun and 1.6.0_0 openjdk. I don't know anything about ant or the security error, but this is look
to me.
Comment by Assembla Importer [ 24/Aug/10 12:45 AM ]
achimpassen said: It works for me on 1.6.0_13 and 1.5.0_19 (32 and 64 bit) on OS X 10.5.7.
Comment by Assembla Importer [ 24/Aug/10 12:45 AM ]
[email protected] said: (In [[r:895b39dabc17b3fd766fdbac3b0757edb0d4b60d]]) Rev fa3d2497 causes compil
on some VMs – back it out. Refs #124
Branch: master
Comment by Assembla Importer [ 24/Aug/10 12:45 AM ]
mikehinchey said: I got the same compile error on both 1.5.0_11 and 1.6.0_14 on Windows. Achim's patch fixes
See the note for "permissions" on http://ant.apache.org/manual/CoreTasks/java.html . I assume
ThreadPoolExecutor.shutdown is the problem, it would shutdown the main Ant thread, so Ant disallows that. Fo
avoids the permissions limitation.
In addition, since the build error still resulted in "BUILD SUCCESSFUL", I think failonerror="true" should also
to the java call so the build would totally fail for such an error.
Comment by Assembla Importer [ 24/Aug/10 12:45 AM ]
[email protected] said: I don't know if the <java fork=true> patch is a good idea or not, or if there's a better wa
the original problem.
Chas, I'm kicking back to you, but I guess if you don't want it you can reassign to "nobody".
Comment by Assembla Importer [ 24/Aug/10 12:45 AM ]
richhickey said: Updating tickets (#8, #42, #113, #2, #20, #94, #96, #104, #119, #124, #127, #149, #162)
Comment by Assembla Importer [ 24/Aug/10 12:45 AM ]
shoover said: I'd like to suggest an alternate approach. There are already well-defined and intuitive ways to block
and futures. Why not deprecate shutdown-agents and force users to call await and deref if they really want to blo
pmap situation one would have to evaluate the pmap form.
The System.exit problem goes away if you configure the threadpools to use daemon threads (call new ThreadPoo
and pass a thread factory that creates threads and sets daemon to true). That way the user has an explicit means o
and System.exit won't hang.
Comment by Assembla Importer [ 24/Aug/10 12:45 AM ]
alexdmiller said: I blogged about these issues at:
http://tech.puredanger.com/2010/06/08/clojure-agent-thread-pools/
I think that:




agent thread pool threads should be named (see ticket #378)
agent thread pools must be daemon threads by default
having ways to specify an customized executor pool for an agent send/send-off is essential to customize
behavior
(shutdown-agents) should be either deprecated or made less dangerous
Comment by Alexander Taggart [ 11/Jul/11 9:33 PM ]
Rich, what is the intention behind using non-daemon threads in the agent pools?
If it is because daemon threads could terminate before their work is complete, would it be acceptable to add a sh
hook to ensure against such premature termination? Such a shutdown hook could call Agent.shutdown(), then
awaitTermination() on the pools.
Comment by Christopher Redinger [ 27/Nov/12 3:47 PM ]
Moving this ticket out of approval "OK" status, and dropping the priority. These were Assembla import defaults.
Also, Chas gets to be the Reporter now.
Comment by Chas Emerick [ 27/Nov/12 5:56 PM ]
Heh, blast from the past.
The comment import appears to have set their timestamps to the date of the import, so the conversation is pretty
follow, and obviously doesn't benefit from the intervening years of experience. In addition, there have been plen
changes to agents, including some recent enhancements that address some of the pain points that Alex Miller me
above.
I propose closing this as 'invalid' or whatever, and opening one or more new issues to track whatever issues still
(presumably based on fresh ML discussion, etc).
Comment by Andy Fingerhut [ 27/Nov/12 6:11 PM ]
Rereading the original description of this ticket, without reading all of the comments that follow, that description
right on target for the behavior of latest Clojure master today.
People send messages to the Clojure Google group every couple of months hitting this issue, and one even filed
of hitting it. I have updated the examples on ClojureDocs.org for future, and also for pmap and clojure.java.shell
use future in their implementations, to warn people about this and explain that they should call (shutdown-agents
making it unnecessary to call shutdown-agents would be even better, at least as the default behavior. It sounds fi
to provide a way for experts on thread behavior to change that default behavior if they need to.
Comment by Andy Fingerhut [ 31/Jul/14 6:39 PM ]
Patch clj-124-v1.patch dated Jul 31 2014 implements the approach of calling clojure.lang.Agent#shutdown when
Var *auto-shutdown-agents* is true, which is its default value.
I don't see any benefit to making this Var dynamic. Unless I am missing something, only the root binding value i
after clojure.main/main returns, not any binding that would be pushed on top of that if it were dynamic. It seems
alter-var-root to change it to false in a way that this patch would avoid calling clojure.lang.Agent#shutdown.
This patch only adds the shutdown call to clojure.main#main, but can easily be added to the legacy_repl and lega
methods if desired.
Comment by Andy Fingerhut [ 23/Aug/14 11:49 AM ]
Patch clj-124-daemonthreads-v1.patch dated Aug 23 2014 simply modifies the ThreadFactory so that every threa
in an agent thread pool is a daemon thread.
Generated at Thu May 04 11:17:25 CDT 2017 using JIRA 4.4#649-r158309.