clojure-based non-blocking webserver like Node.js

[billh2233]

Is there a clojure-based webserver that uses non-blocking IO like
Node.js, or any effort like that being considered?

I like Node.js's non-blocking IO for performance reasons, though it is
built around a single-threaded model whereas clojure is built around a
multi-core/concurrency model. I wonder if the two concepts can be
combined somehow.

Thoughts?

[Laurent PETIT]

Hi,

AFAIK, there's a java version of node.js, called Node.x :

https://github.com/purplefox/node.x

HTH,

-- 

Laurent

2011/9/2 billh2233 <bill....@gmail.com>

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

[Wilson MacGyver]

look at https://github.com/ztellman/aleph

it supprorts async, websocket, server side and client side, plus has
redis support.
very happy with it.

> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

--
Omnem crede diem tibi diluxisse supremum.

[Raoul Duke]

On Fri, Sep 2, 2011 at 11:20 AM, billh2233 <bill....@gmail.com> wrote:
> I like Node.js's non-blocking IO for performance reasons, though it is
> built around a single-threaded model whereas clojure is built around a
> multi-core/concurrency model.  I wonder if the two concepts can be
> combined somehow.

* python lets you combine processes, pre-emptive threads, and
coroutines. see the greenlet stuff.

* class threads are heavy and context switches suck and that is one
reason people don't like them vs. the node.js speeds. however, look at
Erlang since it has very low context switching overhead, since it
doesn't use OS threads.
http://thatclevershark.org/benchmarks.html

* theoretically, threads and event-driven styles are duals of each
other, or maybe the same thing at some level.
http://lamp.epfl.ch/~phaller/doc/haller07actorsunify.pdf
http://www.bluishcoder.co.nz/2006/04/unifying-events-and-threads-in-haskell.html

sincerely.

[Michael Klishin]

2011/9/2 billh2233 <bill....@gmail.com>

Is there a clojure-based webserver that uses non-blocking IO like
Node.js, or any effort like that being considered?

Java ecosystem has at least two very mature asynchronous I/O libraries: Netty and Apache MINA.

Several Clojure projects that use Netty (http://www.jboss.org/netty):

https://github.com/ztellman/aleph

https://github.com/strobecorp/picard

https://github.com/texodus/saturnine

 

--
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

[Tal Liron]

Jetty and Grizzly also work great, and can be used as easily swappable connectors for Restlet, which in turn is used by Prudence's Clojure flavor (I'm the lead developer):

http://threecrickets.com/prudence/

Jetty is the most mature of the bunch (Grizzly, Netty, MINA, etc.) and offers many more features.

I always ask, though, why people think they need async I/O for a web server. Async might be important if you are streaming video, audio, etc. (And if you are, you're probably better off with a robust CDN.) But if your goal is to dynamically produce HTML, then async is close to meaningless: in the end, there must be a thread that generates the HTML (or fetched it from a cache), and that thread is likely in a pool. Sure, the socket may be read asynchronously, but you still have a thread pool at the top, with all the concerns to scalability that it entails.

In fact, it's well known that some of the best performing static-file web servers are not async. For static-file web servers, async might help scalability, not performance (often these qualities are in opposition): it can help you degrade more gracefully per client under very high concurrency. But, depending on what you're doing, any kind of degradation may be unacceptable, and the real solution is probably to scale up/out.

I wrote a long article examining these challenges as part of the Prudence Manual. There is a section that addresses async, and also highlights a select few use cases for it:

http://threecrickets.com/prudence/scaling/#toc-Subsubsection-151

[Andreas Kostler]

Can someone explain please what class threads are?? And whether is threads are expensive depends on the is

[Sergey Didenko]

On Sat, Sep 3, 2011 at 3:01 AM, Tal Liron <tal....@gmail.com> wrote:

I always ask, though, why people think they need async I/O for a web server. Async might be important if you are streaming video, audio, etc. (And if you are, you're probably better off with a robust CDN.)

Async can also be good for chat-like services. Though it is probably overkill for the most other cases.