Pablo Fernandez

While trying to understand the behaviour of my implementation of server side JavaScript execution for pre-rendering SPAs (Single Page Applications), something I’ll write about later on, I quickly run out of memory on Heroku. What I believe was going on is that my Heroku machine was trying to handle too many requests at the same time.

The change to allow specifying how many threads Jetty will use was not hard, but I was surprised I didn’t find it documented explicitly anywhere, so, here it is. My app, created from the re-agent template, had the following -main  function:

(defn -main [& args]
  (let [port (Integer/parseInt (or (env :port) "3000"))]
    (run-jetty app {:port port :join? false})))

which I converted into:

(defn -main [& args]
  (let [config {:port        (Integer/parseInt (or (env :port) "3000"))
                :join?       false
                :min-threads (when (env :min-threads) (Integer/parseInt (env :min-threads)))
                :max-threads (when (env :max-threads) (Integer/parseInt (env :max-threads)))}
        config (reduce-kv #(if (not (nil? %3)) (assoc %1 %2 %3) %1) {} config)]
    ;;(println "Running with config:" config)
    (run-jetty app config)))

that reads the environment variables MAX_THREADS and MIN_THREADS, otherwise, it uses Jetty’s defaults.

Photo by Christopher Bulle