CPU pins at 100% when quitting sbt console

[Runar Bjarnason]

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]

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]

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]

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]

I'm making some progress on this issue if anybody wants to follow along, or help!

https://github.com/dispatch/reboot/issues/58

[Nathan Hamblen]

Is anybody using dispatch.DaemonThreads directly? I'm now thinking this
should be private [dispatch].

[eugene yokota]

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]

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]

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]

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]

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]

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]

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.