@ag Yeah that should be fixed in 0.8.0 - if you try it, please report back

yeah, I’m trying but I can find how it supposed to work ;(

@ag It shouldn't require anything -- once the task exits, the server should be shut down gracefully now, freeing up the port

but how do I force “exit” the task like this:

(deftask dev
  "Main build task for the local development"
  []
  (comp
   (dev-env)
   (npm-install)
   (sassc)
   (watch)
   (serve :reload true)
   (notify :audible true :theme "woodblock"
           :visual true :title "finops-admin")
   (reload :on-jsload 'finops-admin.app/init)
   (cljs-repl)
   (cljs)))

How are you calling that task?

Doesn't that block your REPL?

it doesn’t… so if I run it in terminal, like $> boot repl and then (boot (dev)) - I think then it would

I'm not sure how cider is running that -- have you ever been able to stop that task?

ie, it seems like the question is more about how to stop a task autostarted by cider, rather than specific to boot-http?

if I have a non blocking task e.g. (future (boot (dev)) then restarting it shouldn’t be a problem, no?

If I run it again, it should work, right? but serve has to restart jetty, how do I force it?

it seems even when it’s blocking: I press C-c - it says Stopping jetty, I would start the task again (blocking fashion (boot (dev)) - it’s blocking because watch is blocking. It still would complain: Java.net.BindException: Address already in use

Yeah, I think there was a bug that was keeping Jetty from actually being stopped. Like I said, try 0.8.0 -- should be fixed.

I’m talking about [pandeiro/boot-http “0.8.0”]

would it be possible to expose stop-server, so it could be explicitly stoped?

@ag I just tried exiting with C-c C-c and I'm able to re-run the serve task again from the REPL

I do see a java.lang.InterruptedException thrown from Jetty though, not sure what's up with that

So it exits properly (ie, jetty exits, port is released) if I do (boot (serve))... But if serve is part of a pipeline, such as (boot (comp (serve) (wait))), there is that exception and the boot process seems to go into some kind of loop, pegging multiple cores 😕

Hrm. That's interesting.

I'm going to poke around at that a bit

@bhagany here's a gist with the stacktrace: https://gist.github.com/pandeiro/7c81bed35fb00a7154df505c72182e0c

My attempts of stopping and restarting the task I posted previously aren’t sucessfull

although it does say “stopping Jetty”

@ag if I do two C-cs, it stops. It throws the exception each time, but hey, it stops

@pandeiro regarding the exception, it looks like jetty thinks it's in the middle of serving requests for some reason. still working on that

@bhagany maybe something wrong in my task? https://clojurians.slack.com/archives/C053K90BR/p1493078741815433

@ag C-c doesn't work?

I don't see anything wrong with your task

it says “stopping Jetty”, I start the task again, it says: Address already in use

if it gets to the point of printing that output, I don't see how it wouldn't be calling the stop fn

the exception also seems to be cider-related. boot serve wait on the command line exits cleanly when interrupted

maybe it always did, though

I’m not trying in cider, trying in terminal

I’ve tried (boot (comp (serve)(wait))) - it worked. But how do I stop it when it starts “non-blocking”, e.g. $> boot serve wait repl?

In that case, I don't think you can stop it without also stopping the repl

That’s my point - that’s what I’ve been asking for quite sometime: Is it possible to somehow stop the jetty server? or expose the jetty server (so it can be explicitly stopped) that serve runs?

okay, I haven't followed you until now, I thought you were restarting the whole task. I'm not sure what you want to do fits with the boot model

I don't really see how boot-http could expose the jetty server in the way that you'd need

granted, I've thought about it for all of a minute

I'm not sure I see a good way, either -- but I also don't understand why you'd want to restart Jetty -- is it just to pick up on changes?

@bhagany interesting yeah that exception only happens at the REPL

serve task technically is the only reason right now preventing me from staying in the repl all the time - repl still needs to be restarted from time to time

@ag what does restarting the server accomplish?

@bhagany it seems repl-related, but not cider-related (i was able to produce exception at a vanilla boot repl)

same, I had just tried that. Still references nrepl though... I'm trying to figure out a way to start a repl without involving nrepl, if that's possible...

I think that's going to take a lot of ceremony, might not be worth it

oh shit… I think I was able to completely restart it…

well that's interesting

I’m not sure about (boot (cleanup))…

but it’s stopping it

¯\(ツ)/¯

well… cleanup is not doing anything here. Turn out calling (boot) by itself stops Jetty

could this be a completely new problem now?

I think the problem is here: https://github.com/boot-clj/boot/blob/743eb0599770cc3418160841495a3aaa222567f9/boot/core/src/boot/core.clj#L1035

no... wait, nevermind

backing up a step, my hypothesis is that that finally never gets called

calling (boot) again does call the finally, which stops the server

so that’s normal?

I'd say it's pretty odd for a finally not to get called

I would like to explore what the command line entry point is doing differently from the boot fn, but I'm having trouble finding where that's implemented

I am wrong about this... do-cleanup! is in fact called

new hypothesis: the SIGINT is killing Jetty via a path that's not the finally clause in the boot fn. That path is faster than finally, and so when the finally triggers, it finds that it can't connect to Jetty in order to stop it, and throws

however, if that's correct, I have no idea how to track down that faster path

the docs for CountDownLatch.await support this hypothesis: http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7u40-b43/java/util/concurrent/CountDownLatch.java#235

tl;dr - await throws InterruptedException if the thread has already been interrupted

if anyone has any idea what to do about that, I'm all ears

haven't followed the discussion, but InterruptedException is the Java way to give a chance to a thread to stop cleanly, so it can be thrown at any point in time: a relevant blog post here: http://www.yegor256.com/2015/10/20/interrupted-exception.html

dunno if it is helpful actually

can't hurt 🙂

I'll read it after I'm done trying the dumbest thing possible

alas, neither the article nor the dumbest thing possible has given me any insight

@jjmojojjmojo thanks I'll take a look.

@pjullah If you run into any problems with boot-refresh, let me know

@samestep will do, thanks. I've got it working the way I want - almost.

@richiardiandrea thanks for posting that. i finally understand Thread.interrupt() and InterruptedException. i feel enlightened!

Is there any way to exclude dependencies of dependencies when building an uberjar with boot?

An example I have is where a dependency of my project is basically a Java library wrapper that imports many dependencies that I’m not using, which takes unnecessary resources

@looveh you can specify :exclusions per dependency which will remove them

[org.clojure/clojurescript "0.0.0" :exclusions [org.clojure/clojure]]

@martinklepsch Great, thanks!

is there some specific nrepl middleware (or a setting maybe) that will give me full stack traces when there’s an unhandled exception in boot repl?

the -v option to boot might help there

@jjmojojjmojo running (pst) after an exception happens will print the stacktrace, if that helps

Does anyone know their way around Docker here?