Hi Deyan, Modern web development tends to emphasise isolating system components into separate processes. Rather than use a monolith container like Tomcat, it's common practice to use an embedded web server combined with a reverse proxy like nginx.
In the architecture I use, I have nginx running on port 80/443. It proxies all requests it gets to an unprivileged port, such as 3000, which my application is listening on. I package my Clojure application as an uberjar with a main method that starts a Ring adapter on port 3000, and a nREPL server on another port, such as 3300. The Clojure app is started via an upstart service that handles log rotation and restarts on crashes. Naturally I have a firewall up, so only ports 80 and 443 are open to the outside world. I talk to nREPL by opening a tunnel over SSH to port 3300. I typically use nREPL for occasional read-only querying of the server, rather than in-place modification. Dynamically modifying an application sounds cool, but in practice it just means your server system is out of sync with the version in your repo, which generally speaking is a bad idea. - James On 4 May 2014 11:47, Deyan Yotsov <de...@yotsov.org> 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. For more options, visit https://groups.google.com/d/optout.
