CPU pins at 100% when quitting sbt console

390 views
Skip to first unread message

Runar Bjarnason

unread,
May 10, 2013, 4:32:45 PM5/10/13
to dispatc...@googlegroups.com
I can reliably reproduce this on my Mac. Hopefully somebody will have insights into what's going on here.

1. sudo httpd
2. sbt
3. console
4. import dispatch._; import Defaults._
5. Http(host("localhost", 80) OK as.String)
6. :q

CPU usage goes to 800% and stays there.

kill -3 dumps a lot of netty IO worker stack traces.

Easy workaround is to `sbt console` instead of `sbt` and then `console`. But still, it's a tad worrisome.

Runar

Nathan Hamblen

unread,
May 11, 2013, 2:37:26 AM5/11/13
to dispatc...@googlegroups.com
Yeah that is weird. The backstory is that a lot of threads factories
must be marked daemon for us to be able to quit the scala console and
return to interactive mode at all. There many to identify in the latest
release, but eventually got to the point where it would exit cleanly--I
thought! I had noticed the behavior at one point but I thought it might
be a bug in the new version of sbt I had just upgraded to.

I don't think that you have to worry about this arising in application
use, it's pretty particular to the unusual situation (as far as most
Java libraries are concerned, including async-http-client) of
interacting in the console and returning to sbt interactive mode, in the
same JVM process.

What's interesting to me is that this doesn't occur when running the
tests; I'm not sure what's different between the way sbt runs a test
session and a console session.

Nathan

eugene yokota

unread,
May 11, 2013, 3:00:13 AM5/11/13
to dispatc...@googlegroups.com
I too saw this behavior last week when I was making a Dispatch plugin, but didn't notice it was
happening every time I exit out of console.
Someone using Play reported CPU pegging to async-http-client: https://github.com/AsyncHttpClient/async-http-client/issues/147

-eugene




--
You received this message because you are subscribed to the Google Groups "Dispatch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dispatch-scala+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.



Nathan Hamblen

unread,
May 13, 2013, 2:23:47 PM5/13/13
to dispatc...@googlegroups.com
On 05/11/2013 09:00 AM, eugene yokota wrote:
> I too saw this behavior last week when I was making a Dispatch plugin,
> but didn't notice it was
> happening every time I exit out of console.
> Someone using Play reported CPU pegging to async-http-client:
> https://github.com/AsyncHttpClient/async-http-client/issues/147

Forking the sbt process seems to work around the problem

fork in run := true

Of course, there are a lot of other effects from that. One is that stdin
won't work, but you can do this

connectInput in run := true

But still, other things (like unfiltered's "run" in sbt behavior) will
not work like normal.

Nathan

n8han

unread,
May 22, 2013, 7:24:09 PM5/22/13
to dispatc...@googlegroups.com
I'm making some progress on this issue if anybody wants to follow along, or help!

Nathan Hamblen

unread,
May 23, 2013, 4:57:53 PM5/23/13
to dispatc...@googlegroups.com
Is anybody using dispatch.DaemonThreads directly? I'm now thinking this
should be private [dispatch].

eugene yokota

unread,
May 23, 2013, 5:12:28 PM5/23/13
to dispatc...@googlegroups.com
I'm not. In general, is there anything app can call to say it's done using dispatch, to say it's going to start again?

-eugene


Nathan Hamblen

unread,
May 23, 2013, 5:16:57 PM5/23/13
to dispatc...@googlegroups.com
On 05/23/2013 05:12 PM, eugene yokota wrote:
> I'm not. In general, is there anything app can call to say it's done
> using dispatch, to say it's going to start again?

Not at present, but I am trying to get things right. Is this so that if
someone tries to quit in between uses, it just exits with no issue?

eugene yokota

unread,
May 23, 2013, 5:33:19 PM5/23/13
to dispatc...@googlegroups.com
Or to conserve resource when I know the task is done.
I was thinking for sbt plugins kind of things, you wouldn't want daemons running around in the background
once the task at hand is handled.

-eugene



Nathan Hamblen

unread,
May 23, 2013, 5:42:40 PM5/23/13
to dispatc...@googlegroups.com
On 05/23/2013 05:33 PM, eugene yokota wrote:
> Or to conserve resource when I know the task is done.
> I was thinking for sbt plugins kind of things, you wouldn't want daemons
> running around in the background
> once the task at hand is handled.

Yeah. I'm starting to think that the Http instances should not
statically share executors and thread factories by default!

Nathan Hamblen

unread,
May 24, 2013, 11:48:50 AM5/24/13
to dispatc...@googlegroups.com
Okay this is how it works with what we have in master:

1. returning to sbt interactive without calling shutdown
a. is still possible
b. no longer takes over the CPU
2. instances created with the default config
a. can now be shut down individually
b. you can always start new instances
c. you can never restart old instances
3. daemon threads are only used in an sbt "trap exit" thread-group [1]
a. daemon threads are no longer used in a forked or separate process
b. you must shutdown Http instances if you want the JVM to terminate
when its main thread completes
c. Most process signals (INT,TERM,HUP) will cause the JVM to
terminate even if Http instances are not shutdown, as before

The reason for 3, which you could consider a regression, is that I had
to do a few hacks to make 1b work and I'm not comfortable with those
being enabled by default outside of a development environment.

If anybody wants a way to explicitly enable the daemon thread hackery,
speak now. I'm inclined to have it be enabled just when we know we're in
sbt's "trap exit" thread-group. For more general cases, the cleanest
thing is to call shutdown when you need it.

[1]:
http://www.scala-sbt.org/0.12.3/docs/Detailed-Topics/Running-Project-Code.html

Nathan

eugene yokota

unread,
May 24, 2013, 8:50:19 PM5/24/13
to dispatc...@googlegroups.com

On Friday, May 24, 2013 11:48:50 AM UTC-4, n8han wrote:
1. returning to sbt interactive without calling shutdown
    a. is still possible
    b. no longer takes over the CPU 

I pulled the master (changed the version to -SNAPSHOT) and tested it locally,
and sbt console exit looks normal with or without explicit shutdown call.

-eugene 

Nathan Hamblen

unread,
May 25, 2013, 10:22:31 AM5/25/13
to dispatc...@googlegroups.com

Thanks for testing! I've published the 0.10.1 artifacts and will announce to implicit.ly soon.


--
You received this message because you are subscribed to the Google Groups "Dispatch" group.

To unsubscribe from this group and stop receiving emails from it, send an email to dispatch-scal...@googlegroups.com.

Reply all
Reply to author
Forward
0 new messages