Many thanks to both of you, your answers were very helpful!
Regards,
Deyan
On 05/04/2014 11:28 PM, Akos Gyimesi wrote:
Hi Deyan,
I also think that it's usually better to have a standalone Clojure app
with a built-in HTTP server, and possibly with a reverse proxy as a
frontend. You will have much more control this way, and Tomcat will
not surprise you with wiping your hotfixes.
About thread handling: it's important to note that Clojure starts some
threads, too. For example, agents run on a dedicated thread pool. So
if you use an external web server, it will only control a few of the
threads in your application.
About app startup: you can start the nREPL and the webserver in
parallel (as James suggested), or you can go on a different route:
start only a webserver, and integrate Drawbridge
<https://github.com/cemerick/drawbridge> (a HTTP transport layer for
nREPL) into the web app. We use this approach in prod, and it has a
few advantages:
1. We can have a web-based console on the admin page, which is often
useful (we can debug from any device that has a browser)
2. Drawbridge is implemented as a Ring handler, so it is easy to
extend it with additional features like user authentication, logging, etc.
3. We generate the full app code+docs with Marginalia, and bundle it
with the web-based REPL. This way we can easily look up the code that
was released to the server, which is usually easier than finding the
commit that runs on the server, and checking it out into our favorite
editor.
Regards,
Akos
On Sun, May 4, 2014, at 03:47 AM, Deyan Yotsov wrote:
> Hello!
>
> I am working on a small Clojure web application, and while still in the
> early stages of development, I have been thinking, among other things,
> about a deployment plan.
>
> The production environment for the webapp will be a CentOS server (not
> virtual), the webapp will be sitting behind an Apache gateway on the
> same machine, the webapp will be deployed in a single instance (no load
> balancing involved), and there will be no ssl support. These pieces of
> information are probably irrelevant to what will follow, but I thought
> I'd include them just in case, and maybe they can be summarized as: I
> will not be using Heroku or Google app engine or Amazon.
>
> I want to leverage the REPL (not Clojurescript browser REPL, but Clojure
> server-side REPL) on prod for two things:
> a. being able to check the status of the webapp by connecting to the
> REPL and querying things, derefing atoms, etc.
> b. hot-deploying small fixes without restarting the webapp by redefining
> not-^:dynamic vars through the REPL
>
> I am very excited about a. and b., but also somewhat unsure about what
> the implications of using them are.
>
> 1. Some web servers, including Tomcat, have the functionality to unload
> a webapp if it is getting no requests for a while, and reload it when a
> request comes in. If I want to use such a web server, I need to make
> sure this functionality is switched off, or otherwise it will interfere
> with b., as live var redefinitions will be lost upon webapp reload,
> correct?
>
> 2. I suppose that the REPL is running in a separate thread. I feel
> uncomfortable with having this thread started by the webapp, especially
> having in mind that it is a long-running thread. The web server is
> already managing a thread pool for handling incoming requests. Ideally,
> this thread pool should also be the one responsible for starting the
> REPL thread. Is there a web server that offers this functionality more
> or less out of the box?
>
> 3. When developing a webapp, it is common to first start a REPL, and
> then, from inside this REPL, start a web server. Would doing the same
> thing for production deployment solve my concern 2.? I guess it should,
> because then the REPL will be the "main" thread, and not some
> long-running thread started by the webapp without the knowledge of the
> web server's thread pool manager. Also, while this way of deploying
> webapps is very different from how it is typically done in the Java
> world, I find it beneficial, as one would typically want to do a bit of
> a. immediately after startup, and have a more transparent startup
> overall. Or are there any indications that this way of starting up is
> not appropriate for prod?
>
> Thank you!
> Deyan
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google
Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it,
send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clojure+unsubscr...@googlegroups.com
<mailto:clojure+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
