<!-- 
RSS generated by JIRA (4.4#649-r158309) at Thu Jun 20 00:38:24 CDT 2013

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary add field=key&field=summary to the URL of your request.
For example:
http://dev.clojure.org/jira/si/jira.issueviews:issue-xml/CLJ-124/CLJ-124.xml?field=key&field=summary
-->
<rss version="0.92" >
<channel>
    <title>Clojure JIRA</title>
    <link>http://dev.clojure.org/jira</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>4.4</version>
        <build-number>649</build-number>
        <build-date>25-07-2011</build-date>
    </build-info>

<item>
            <title>[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</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-124</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;Reported by cemer...@snowtide.com, Jun 01, 2009

There has been intermittent chatter over the past months from a couple of
people on the group (e.g.
http:&lt;span class=&quot;code-comment&quot;&gt;//groups.google.com/group/clojure/browse_thread/thread/409054e3542adc1f)
&lt;/span&gt;and in #clojure about some clojure scripts hanging, either &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; 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 &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt; 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 &lt;span class=&quot;code-keyword&quot;&gt;finally&lt;/span&gt; block in
clojure.lang.Compile/main resolved the problem; a patch including &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt;
change is attached.  I wouldn&apos;t suspect anyone would have any issues with
such a change.

-----
In general, it doesn&apos;t seem like everyone should keep tripping over &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt;
problem in different directions.  It&apos;s a very difficult thing to debug &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt;
you&apos;re not attuned to how clojure&apos;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* &lt;span class=&quot;code-keyword&quot;&gt;var&lt;/span&gt;, which:

- &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt; when exiting one of the main entry points (clojure.main, or the
legacy script/repl entry points), Agent.shutdown() would be called,
allowing &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; the clean exit of the application

- would be bound by &lt;span class=&quot;code-keyword&quot;&gt;default&lt;/span&gt; to &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;

- could be easily set to &lt;span class=&quot;code-keyword&quot;&gt;false&lt;/span&gt; &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; anyone with an advanced use-&lt;span class=&quot;code-keyword&quot;&gt;case&lt;/span&gt; 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 &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt; may represent the best compromise between
least-surprise and maximal functionality &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; 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&apos;s
Executors.  Currently, Actor uses a &lt;span class=&quot;code-keyword&quot;&gt;default&lt;/span&gt; thread pool executor, which
results in a 60s keepalive.  Lowering &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt; to something much smaller (1s?
5s?) would additionally minimize the impact of Agent&apos;s threadpools on Java
applications that embed clojure directly (and would therefore not benefit
from *auto-shutdown-agents* as currently conceived, leading to puzzling
&apos;hanging&apos; behaviour).  I&apos;m not in a position to determine what impact &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt;
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 cemer...@snowtide.com, Jun 01, 2009

Just FYI, I&apos;d be happy to provide patches &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; either of the suggestions mentioned
above...&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="13521">CLJ-124</key>
            <summary>GC  Issue 120: Determine mechanism for controlling automatic shutdown of Agents, with a default policy and mechanism for changing that policy as needed</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="cemerick">Chas Emerick</assignee>
                                <reporter username="cemerick">Chas Emerick</reporter>
                        <labels>
                    </labels>
                <created>Wed, 17 Jun 2009 23:24:00 -0500</created>
                <updated>Fri, 12 Apr 2013 09:52:24 -0500</updated>
                                                    <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>3</votes>
                        <watches>5</watches>
                        <comments>
                    <comment id="22862" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;Converted from &lt;a href=&quot;http://www.assembla.com/spaces/clojure/tickets/124&quot;&gt;http://www.assembla.com/spaces/clojure/tickets/124&lt;/a&gt;&lt;br/&gt;
Attachments:&lt;br/&gt;
compile-agent-shutdown.patch - &lt;a href=&quot;https://www.assembla.com/spaces/clojure/documents/a56S2ow4ur3O2PeJe5afGb/download/a56S2ow4ur3O2PeJe5afGb&quot;&gt;https://www.assembla.com/spaces/clojure/documents/a56S2ow4ur3O2PeJe5afGb/download/a56S2ow4ur3O2PeJe5afGb&lt;/a&gt;&lt;br/&gt;
124-compilation.diff - &lt;a href=&quot;https://www.assembla.com/spaces/clojure/documents/aqn0IGxZSr3RUGeJe5aVNr/download/aqn0IGxZSr3RUGeJe5aVNr&quot;&gt;https://www.assembla.com/spaces/clojure/documents/aqn0IGxZSr3RUGeJe5aVNr/download/aqn0IGxZSr3RUGeJe5aVNr&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="22863" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;oranenj said: [&lt;a href=&quot;file:a56S2ow4ur3O2PeJe5afGb&quot;&gt;file:a56S2ow4ur3O2PeJe5afGb&lt;/a&gt;]&lt;/p&gt;</comment>
                    <comment id="22864" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;richhickey said: Updating tickets (#8, #19, #30, #31, #126, #17, #42, #47, #50, #61, #64, #69, #71, #77, #79, #84, #87, #89, #96, #99, #103, #107, #112, #113, #114, #115, #118, #119, #121, #122, #124)&lt;/p&gt;</comment>
                    <comment id="22865" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;cemerick said: (In [&lt;span class=&quot;error&quot;&gt;&amp;#91;r:fa3d24973fc415b35ae6ec8d84b61ace76bd4133&amp;#93;&lt;/span&gt;]) Add a call to Agent.shutdown() at the end of clojure.lang.Compile/main Refs #124&lt;/p&gt;

&lt;p&gt;Signed-off-by: Chouser &amp;lt;chouser@n01se.net&amp;gt;&lt;/p&gt;

&lt;p&gt;Branch: master&lt;/p&gt;</comment>
                    <comment id="22866" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;chouser@n01se.net said: I&apos;m closing this ticket to because the attached patch solves a specific problem.  I agree that the idea of an &lt;b&gt;auto-shutdown-agents&lt;/b&gt; var sounds like a positive compromise.  If Rich wants a ticket to track that issue, I think it&apos;d be best to open a new ticket (and perhaps mention this one there) rather than use this ticket to track further changes.&lt;/p&gt;</comment>
                    <comment id="22867" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;scgilardi said: With both Java 5 and Java 6 on Mac OS X 10.5 Leopard I&apos;m getting an error when compiling with this change present.&lt;/p&gt;

&lt;p&gt;Java 1.5.0_19&lt;br/&gt;
Java 1.6.0_13&lt;/p&gt;

&lt;p&gt;For example, when building clojure using &quot;ant&quot; from within my clone of the clojure repo:&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;java&amp;#93;&lt;/span&gt; java.security.AccessControlException: access denied (java.lang.RuntimePermission modifyThread)&lt;br/&gt;
     &lt;span class=&quot;error&quot;&gt;&amp;#91;java&amp;#93;&lt;/span&gt;  at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)&lt;br/&gt;
     &lt;span class=&quot;error&quot;&gt;&amp;#91;java&amp;#93;&lt;/span&gt;  at java.security.AccessController.checkPermission(AccessController.java:427)&lt;br/&gt;
     &lt;span class=&quot;error&quot;&gt;&amp;#91;java&amp;#93;&lt;/span&gt;  at java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:894)&lt;br/&gt;
     &lt;span class=&quot;error&quot;&gt;&amp;#91;java&amp;#93;&lt;/span&gt;  at clojure.lang.Agent.shutdown(Agent.java:34)&lt;br/&gt;
     &lt;span class=&quot;error&quot;&gt;&amp;#91;java&amp;#93;&lt;/span&gt;  at clojure.lang.Compile.main(Compile.java:71)&lt;/p&gt;

&lt;p&gt;I reproduced this on two Mac OS X 10.5 machines. I&apos;m not aware of having any enhanced security policies along these lines on my machines. The compile goes fine for me with Java 1.6.0_0 on an Ubuntu box.&lt;/p&gt;</comment>
                    <comment id="22868" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;chouser@n01se.net said: I had only tested it on my ubuntu box &amp;#8211; looks like that was openjdk 1.6.0_0.  I&apos;ll test again with sun-java5 and sun-java6.&lt;/p&gt;</comment>
                    <comment id="22869" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;chouser@n01se.net said: 1.6.0_13 worked fine for me on ubuntu, but 1.5.0_18 generated an the exception Steve pasted.  Any suggestions?  Should this patch be backed out until someone has a fix?&lt;/p&gt;</comment>
                    <comment id="22870" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;achimpassen said: [&lt;a href=&quot;file:aqn0IGxZSr3RUGeJe5aVNr&quot;&gt;file:aqn0IGxZSr3RUGeJe5aVNr&lt;/a&gt;]&lt;/p&gt;</comment>
                    <comment id="22871" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;chouser@n01se.net said: With Achim&apos;s patch, clojure compiles for me on ubuntu using java 1.5.0_18 from sun, and still works on 1.6.0_13 sun and 1.6.0_0 openjdk.  I don&apos;t know anything about ant or the security error, but this is looking good to me.&lt;/p&gt;</comment>
                    <comment id="22872" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;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.&lt;/p&gt;</comment>
                    <comment id="22873" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;chouser@n01se.net said: (In [&lt;span class=&quot;error&quot;&gt;&amp;#91;r:895b39dabc17b3fd766fdbac3b0757edb0d4b60d&amp;#93;&lt;/span&gt;]) Rev fa3d2497 causes compile to fail on some VMs &amp;#8211; back it out. Refs #124&lt;/p&gt;

&lt;p&gt;Branch: master&lt;/p&gt;</comment>
                    <comment id="22874" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;mikehinchey said: I got the same compile error on both 1.5.0_11 and 1.6.0_14 on Windows.  Achim&apos;s patch fixes both.&lt;/p&gt;

&lt;p&gt;See the note for &quot;permissions&quot; on &lt;a href=&quot;http://ant.apache.org/manual/CoreTasks/java.html&quot;&gt;http://ant.apache.org/manual/CoreTasks/java.html&lt;/a&gt; .  I assume ThreadPoolExecutor.shutdown is the problem, it would shutdown the main Ant thread, so Ant disallows that.  Forking avoids the permissions limitation.&lt;/p&gt;

&lt;p&gt;In addition, since the build error still resulted in &quot;BUILD SUCCESSFUL&quot;, I think failonerror=&quot;true&quot; should also be added to the java call so the build would totally fail for such an error.&lt;/p&gt;</comment>
                    <comment id="22875" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;chouser@n01se.net said: I don&apos;t know if the &amp;lt;java fork=true&amp;gt; patch is a good idea or not, or if there&apos;s a better way to solve the original problem.&lt;/p&gt;

&lt;p&gt;Chas, I&apos;m kicking back to you, but I guess if you don&apos;t want it you can reassign to &quot;nobody&quot;.&lt;/p&gt;</comment>
                    <comment id="22876" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;richhickey said: Updating tickets (#8, #42, #113, #2, #20, #94, #96, #104, #119, #124, #127, #149, #162)&lt;/p&gt;</comment>
                    <comment id="22877" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;shoover said: I&apos;d like to suggest an alternate approach. 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.&lt;/p&gt;

&lt;p&gt;The System.exit problem goes away if you configure the threadpools to use daemon threads (call new ThreadPoolExecutor and pass a thread factory that creates threads and sets daemon to true). That way the user has an explicit means of blocking and System.exit won&apos;t hang.&lt;/p&gt;</comment>
                    <comment id="22878" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;alexdmiller said: I blogged about these issues at:&lt;br/&gt;
&lt;a href=&quot;http://tech.puredanger.com/2010/06/08/clojure-agent-thread-pools/&quot;&gt;http://tech.puredanger.com/2010/06/08/clojure-agent-thread-pools/&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I think that:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;agent thread pool threads should be named (see ticket &lt;a href=&quot;https://www.assembla.com/spaces/clojure/tickets/378-set-thread-names-on-agent-thread-pools&quot;&gt;#378&lt;/a&gt;)&lt;/li&gt;
	&lt;li&gt;agent thread pools must be daemon threads by default&lt;/li&gt;
	&lt;li&gt;having ways to specify an customized executor pool for an agent send/send-off is essential to customize threading behavior&lt;/li&gt;
	&lt;li&gt;(shutdown-agents) should be either deprecated or made less dangerous&lt;/li&gt;
&lt;/ul&gt;
</comment>
                    <comment id="26565" author="ataggart" created="Mon, 11 Jul 2011 21:33:24 -0500"  >&lt;p&gt;Rich, what is the intention behind using non-daemon threads in the agent pools?&lt;/p&gt;

&lt;p&gt;If it is because daemon threads could terminate before their work is complete, would it be acceptable to &lt;a href=&quot;http://download.oracle.com/javase/1.5.0/docs/api/java/lang/Runtime.html#addShutdownHook(java.lang.Thread)&quot;&gt;add a shutdown hook&lt;/a&gt; to ensure against such premature termination?  Such a shutdown hook could call &lt;tt&gt;Agent.shutdown()&lt;/tt&gt;, then &lt;a href=&quot;http://download.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/ExecutorService.html#awaitTermination(long, java.util.concurrent.TimeUnit)&quot;&gt;&lt;tt&gt;awaitTermination()&lt;/tt&gt;&lt;/a&gt; on the pools.&lt;/p&gt;</comment>
                    <comment id="30069" author="redinger" created="Tue, 27 Nov 2012 15:47:20 -0600"  >&lt;p&gt;Moving this ticket out of approval &quot;OK&quot; status, and dropping the priority. These were Assembla import defaults.&lt;/p&gt;

&lt;p&gt;Also, Chas gets to be the Reporter now.&lt;/p&gt;</comment>
                    <comment id="30072" author="cemerick" created="Tue, 27 Nov 2012 17:56:24 -0600"  >&lt;p&gt;Heh, blast from the past.&lt;/p&gt;

&lt;p&gt;The comment import appears to have set their timestamps to the date of the import, so the conversation is pretty hard to follow, and obviously doesn&apos;t benefit from the intervening years of experience.  In addition, there have been plenty of changes to agents, including some &lt;a href=&quot;https://github.com/clojure/clojure/commit/f5f4faf&quot;&gt;recent enhancements&lt;/a&gt; that address some of the pain points that Alex Miller mentioned above.&lt;/p&gt;

&lt;p&gt;I propose closing this as &apos;invalid&apos; or whatever, and opening one or more new issues to track whatever issues still persist (presumably based on fresh ML discussion, etc).&lt;/p&gt;</comment>
                    <comment id="30073" author="jafingerhut" created="Tue, 27 Nov 2012 18:11:09 -0600"  >&lt;p&gt;Rereading the original description of this ticket, without reading all of the comments that follow, that description is still right on target for the behavior of latest Clojure master today.&lt;/p&gt;

&lt;p&gt;People send messages to the Clojure Google group every couple of months hitting this issue, and one even filed &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-959&quot; title=&quot;after call to clojure.java.shell/sh, jvm won&amp;#39;t exit&quot;&gt;CLJ-959&lt;/a&gt; because of hitting it.  I have updated the examples on ClojureDocs.org for future, and also for pmap and clojure.java.shell/sh which use future in their implementations, to warn people about this and explain that they should call (shutdown-agents), but making it unnecessary to call shutdown-agents would be even better, at least as the default behavior.  It sounds fine to me to provide a way for experts on thread behavior to change that default behavior if they need to.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10003">Vetted</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                        <customfield id="customfield_10003" key="com.atlassian.jira.plugin.system.customfieldtypes:userpicker">
                <customfieldname>Waiting On</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>richhickey</customfieldvalue>
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>
</channel>
</rss>