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.

Reply via email to