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

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s