roberto Wrote:
-------------------------------------------------------
>
> Sorry, but are you saying that your suggested usage for concurrency is
> multiprocessing ?
>
> Multiprocessing is completely alien in the jvm (the vm is not even
> fork-friendly) and that would mean the nginx worker completly give
> control
> to the jvm and this is something bad as the jvm is a blocking vm.
>
> The jvm world is thread-centric (and trust me, i needed to deal with
> dozens of different threading implementations for uWSGI and the jvm is
> the
> best one) so i am quite doubtful saying "multiprocess by default"
> would be
> a successfull approach (well the amount of memory per-app will be
> huge)
>
>
> --
> Roberto De Ioris
> http://unbit.it
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx

One Nginx worker , typically single thread, can handle thousands of request by non-blocking events. So we need less Nginx workers than the threads in a typical java server.

Java thread is not lightweight and uses more memory than general thread.

I don't think JVM is blocking vm. In my eye JVM just a executor of java class. By JNI we can any no-blocking things just as a general Nginx modula written by c.

With the default mode in Nginx-Clojure 0.1.0 there 's one jvm instance embed per Nginx worker. The will be some no-blocking api provided by the next version of Nginx-Clojure.

With Nginx-Clojure 0.1.0 you can also use one JVM instance with a thread pool if you like, just set nginx worker processes = 1 and set jvm_workers = the number of java threads you will use.