0
votes

I'm writing an embedded Jetty app in Clojure, and have the following as the main namespace:

(ns rudkus.core
  (:require [clojure.tools.cli :as cli]
            [ring.adapter.jetty :as jetty])
  (:gen-class))

(defn handler [request]
  {:status 200
   :headers {"Content-Type" "text/html"}
   :body "Hello, World!"})

(def ^{:private true} server (atom nil))

(defn start [port]
  (swap! server #(if (not (nil? %))
                  (throw (IllegalStateException. "Server already started."))
                  (jetty/run-jetty handler
                                   {:port port
                                    :join? false}))))

(defn stop []
  (swap! server #(if (nil? %)
                  (throw (IllegalStateException. "Server already stopped."))
                  (do (.stop %)
                      nil))))

(defn -main [& args]
  (let [[options extra-args banner] (cli/cli args
                                             ["-p" "--port" "Port" :default 80 :parse-fn #(Integer. %)])]
    (if (not-empty extra-args)
      (println banner)
      (start (:port options)))))

This works OK - I want to be able to start and stop via REPL, as well as start and start from the console in which the JAR is running (though if there's a better pattern for start/stop of a Clojure-Ring-Jetty program, I'd love to know). The issue is if I run

lein run

or

lein trampoline run

and there's an exception thrown by jetty/run-jetty (which wraps a Server.start() call) - for example, on my MacBook Pro, if I try to start the Jetty server on port 80, it barfs - the Clojure program doesn't exit. However, the exception is in thread "main". So why wouldn't the program exit? The only thing I can think of is that Jetty has threads floating around. But start() failed!!! So what is/are these thread(pool)(s) doing?

Is this a Java thing, a Clojure thing, a Leiningen thing, a Jetty thing, or a Ring thing?

EDIT:

Here is the stacktrace:

$ java -jar rudkus-0.1.0-SNAPSHOT-standalone.jar
2012-09-09 15:54:59.664:INFO:oejs.Server:jetty-7.x.y-SNAPSHOT
2012-09-09 15:54:59.803:WARN:oejuc.AbstractLifeCycle:FAILED [email protected]:80: java.net.SocketException: Permission denied
java.net.SocketException: Permission denied
    at sun.nio.ch.Net.bind(Native Method)
    at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:124)
    at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
    at org.eclipse.jetty.server.nio.SelectChannelConnector.open(SelectChannelConnector.java:173)
    at org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:311)
    at org.eclipse.jetty.server.nio.SelectChannelConnector.doStart(SelectChannelConnector.java:251)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)
    at org.eclipse.jetty.server.Server.doStart(Server.java:272)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)
    at ring.adapter.jetty$run_jetty.invoke(jetty.clj:86)
    at rudkus.core$start$fn__16.invoke(core.clj:16)
    at clojure.lang.Atom.swap(Atom.java:37)
    at clojure.core$swap_BANG_.invoke(core.clj:2108)
    at rudkus.core$start.invoke(core.clj:14)
    at rudkus.core$_main.doInvoke(core.clj:31)
    at clojure.lang.RestFn.invoke(RestFn.java:397)
    at clojure.lang.AFn.applyToHelper(AFn.java:159)
    at clojure.lang.RestFn.applyTo(RestFn.java:132)
    at rudkus.core.main(Unknown Source)
2012-09-09 15:54:59.806:WARN:oejuc.AbstractLifeCycle:FAILED org.eclipse.jetty.server.Server@6e5dfaf1: java.net.SocketException: Permission denied
java.net.SocketException: Permission denied
    at sun.nio.ch.Net.bind(Native Method)
    at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:124)
    at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
    at org.eclipse.jetty.server.nio.SelectChannelConnector.open(SelectChannelConnector.java:173)
    at org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:311)
    at org.eclipse.jetty.server.nio.SelectChannelConnector.doStart(SelectChannelConnector.java:251)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)
    at org.eclipse.jetty.server.Server.doStart(Server.java:272)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)
    at ring.adapter.jetty$run_jetty.invoke(jetty.clj:86)
    at rudkus.core$start$fn__16.invoke(core.clj:16)
    at clojure.lang.Atom.swap(Atom.java:37)
    at clojure.core$swap_BANG_.invoke(core.clj:2108)
    at rudkus.core$start.invoke(core.clj:14)
    at rudkus.core$_main.doInvoke(core.clj:31)
    at clojure.lang.RestFn.invoke(RestFn.java:397)
    at clojure.lang.AFn.applyToHelper(AFn.java:159)
    at clojure.lang.RestFn.applyTo(RestFn.java:132)
    at rudkus.core.main(Unknown Source)
Exception in thread "main" java.net.SocketException: Permission denied
    at sun.nio.ch.Net.bind(Native Method)
    at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:124)
    at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
    at org.eclipse.jetty.server.nio.SelectChannelConnector.open(SelectChannelConnector.java:173)
    at org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:311)
    at org.eclipse.jetty.server.nio.SelectChannelConnector.doStart(SelectChannelConnector.java:251)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)
    at org.eclipse.jetty.server.Server.doStart(Server.java:272)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)
    at ring.adapter.jetty$run_jetty.invoke(jetty.clj:86)
    at rudkus.core$start$fn__16.invoke(core.clj:16)
    at clojure.lang.Atom.swap(Atom.java:37)
    at clojure.core$swap_BANG_.invoke(core.clj:2108)
    at rudkus.core$start.invoke(core.clj:14)
    at rudkus.core$_main.doInvoke(core.clj:31)
    at clojure.lang.RestFn.invoke(RestFn.java:397)
    at clojure.lang.AFn.applyToHelper(AFn.java:159)
    at clojure.lang.RestFn.applyTo(RestFn.java:132)
    at rudkus.core.main(Unknown Source)
1
It's possible that -main is spawning non-daemon threads (see stackoverflow.com/questions/2213340/…) - but impossible to know for sure without the stacktrace.noahlz

1 Answers

2
votes

there is a solution if you look at this code (found as an answer on the first page of google results): source code containing method contextStartupFailed() That solution however did not work for me, since it asks for a field named _unavailable using reflection, and my Jetty version (8.1.8.v20121106) does not have such a field.

However, Jetty seams to support something better now. For me, the following works:

  protected static void contextStartupFailed(WebAppContext pContext) throws Exception {

  Throwable failedException = pContext.getUnavailableException();

  if (failedException != null) {
     throw new RuntimeException("Error starting WebContext of Jetty.", failedException);
  }

}

I call that method just after starting Jetty. Of course, this only works if you have a WebAppContext.