Not only Wildfly but also most of mainstream pure java webservers use thread pool to handle http requests. Nginx-Clojure can also be configurated to use thread pool with one or many JVM instances.
Advanced Java webservers use Java NIO (I/O multipexing) to do the first phrase (Http request accepting and simple parsing) then run user business flow with thread pool. The first phrase only need one or very few threads. But at the second phrase (using thread pool) largely existing Java Socket API based libraries such as JDBC drivers, Http Client are blocking so if there are many connections they 'll eat up all threads and make the webserver hang because a OS can only support less threads than connections. By the way threads in JVM are not cheap and they use more memory than pure native OS threads and OS threads are pre-emptive and scheduled at constant time slice so if there are too many threads scheduling will cost too many of cpu cycles to do real works. For large scalar application one JVM instance is really not enough. Typical scenario is we use serveral Java webservers such as tomcat, jetty, glassfish etc, and put a reverse proxy such as Nginx, Haproxy, Apache in the front of them. And Nginx-Clojure make this work easier because it can automatic embed JVM instances into Nginx worker processes and we need not maintain too many webservers. Since JDK 5, JVM instances can share Class data to reduce memory usage and the startup time for java applications. And on our enviroment typically we use coroutine based sockets to work with Apache http client , Solr client ,etc. Coroutines are cooperative and cheaper than threads and be created as much as our memory can bear. Xfeep On Mon, Sep 8, 2014 at 3:27 AM, gvim <gvi...@gmail.com> wrote: > On 07/09/2014 17:51, Yuexiang Zhang wrote: > >> >> From Nginx-Clojure the most attractive things to us is : >> >> 1. Nginx's architecture is Master + Worker processes, Nginx-Clojure >> embed one JVM in per Worker process. So if any of worker process >> crashes, the other JVM instances can still work and the Master will >> recreate a new Worker process embedding with a new JVM instance. >> 2. Nginx's perfect performance when handle even over 10 thousand >> connections >> 3. Coroutine based socket let old Java Socket API based app/libraries >> won't lock a thread anymore >> 4. IO (Coroutine based socket, Asynchronous socket & Channel) are on >> top of Nginx IO API which is more worldly-wise than Java NIO on huge >> scalar server application. >> 5. JVMs are not goot at huge memory management. Configurable multiple >> JVM instances (is the same number of Nginx Worker processes) will >> manage less memory. e.g. we have ten Nginx Worker processes in one >> Nginx instance every JVM instance will only manage 1/10 memory >> 6. Nginx already has many modules / features such as rate limit , >> spdy , pages cache, image filter etc. Most of them maybe are >> difficult or less effective to be implemented in pure Java world. >> >> > I'm fairly new to Clojure/JVM but I was under the impression Java > webservers such as Wildfly (= JBoss) had a reputation for managing memory > efficiently by spawning threads, ie. only a single JVM instance required? > Your scenario with multiple JVMs/1 per worker sounds like a much bigger > memory footprint but, as I said, I'm new to Java. > > > gvim > > -- > 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 a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/clojure/baqWfrei8CE/unsubscribe. > To unsubscribe from this group and all its topics, 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.