long-polling applications

[arj]

Hello

I'm toying with a small project on the side that uses compojure. I
wanted to try my hand with long-polling, since it seems to fit quite
nicely with clojure. One thing I found though, was that it seems that
when the client disconnect that I don't get any exception. It's very
easy to reproduce with a simple thread.sleep. I just would like to
minimize the number of threading spinning. I was wondering if there as
a way to achieve this with compojure and if anyone had any luck toying
with something like long-polling?

Thanks in advance.

--
Anders Rune Jensen
http://people.iola.dk/arj/

[James Reeves]

On Dec 7, 7:05 pm, arj <anders.rune.jen...@gmail.com> wrote:
> I'm toying with a small project on the side that uses compojure. I
> wanted to try my hand with long-polling, since it seems to fit quite
> nicely with clojure. One thing I found though, was that it seems that
> when the client disconnect that I don't get any exception. It's very
> easy to reproduce with a simple thread.sleep. I just would like to
> minimize the number of threading spinning. I was wondering if there as
> a way to achieve this with compojure and if anyone had any luck toying
> with something like long-polling?

I've experimented with long-polling in Clojure myself. I came to the
conclusion that a HTTP framework geared toward handling normal HTTP
request does not make a good Comet server. One is designed around
serving resources; the other is designed to handle events. The
architecture is quite different, despite using the same protocol.

In my view, long polling is best handled by a separate server tied to
a set of subdomains. This server can either be written by hand, based
around something like Jetty with its Continuation Servlets, or use a
light-weight "middleman" like nginx_http_push.

- James

[Lance Carlson]

Couldn't you make your http framework event based? Then you could do
both without too much re-engineering. My concern would be how you
handle the multiple connections. Would you use 1 thread per
connection? It seems this is the recommended way to do this in java
but in c, having less threads can perform better.

Sent from my iPhone

On Dec 7, 2009, at 4:21 PM, James Reeves <weave...@googlemail.com>
wrote:

> --
>
> You received this message because you are subscribed to the Google
> Groups "Compojure" group.
> To post to this group, send email to comp...@googlegroups.com.
> To unsubscribe from this group, send email to compojure+...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/compojure?hl=en
> .
>
>

[Anders Rune Jensen]

Even with a event based framework you are still leaking memory if you
are not cleaning up after yourself.

--
Anders Rune Jensen

http://www.iola.dk
http://people.iola.dk/arj/

[James Reeves]

On Dec 8, 4:30 am, Lance Carlson <lancecarl...@gmail.com> wrote:
> Couldn't you make your http framework event based? Then you could do  
> both without too much re-engineering.

Yes, I could create a web framework that does both, but I don't think
it's a good idea to do so.

Firstly, you can't generate a thread per connection if you want your
application to be performant. You'd quickly run out of threads, as
they're relatively expensive (we're talking less than 10,000
simultaneous connections). Long-polling servers tend to use non-
blocking IO, so you'd need to write something using java.nio.

This means you'd have to drop Ring compatibility and Java servlet
compatibility.

Next you'd need to design your framework around a streaming, event-
based model. In a resource-based model, you need one function that
takes in a request and returns a response. An event-based model is
obviously more complex, as you need to be able to assign many
functions to various events, such as connection, disconnection, data
received, etc. This would be tying yourself to a single Java HTTP
server, or writing your own.

A better idea in my view would be to use two servers. Use a normal
HTTP server for your normal content, and then create a custom HTTP
server designed specifically to handle real-time events.

- James

[Anders Rune Jensen]

I stumpled over the following today. Maybe there is hope after all :)

http://blogs.webtide.com/gregw/entry/jetty_websocket_server

> --
>
> You received this message because you are subscribed to the Google Groups "Compojure" group.
> To post to this group, send email to comp...@googlegroups.com.
> To unsubscribe from this group, send email to compojure+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/compojure?hl=en.
>
>
>

--
Anders Rune Jensen

http://www.iola.dk
http://people.iola.dk/arj/

[Joost]

On 8 dec, 14:28, James Reeves <weavejes...@googlemail.com> wrote:
> On Dec 8, 4:30 am, Lance Carlson <lancecarl...@gmail.com> wrote:
>
> > Couldn't you make your http framework event based? Then you could do  
> > both without too much re-engineering.
>
> Yes, I could create a web framework that does both, but I don't think
> it's a good idea to do so.
>
> Firstly, you can't generate a thread per connection if you want your
> application to be performant. You'd quickly run out of threads, as
> they're relatively expensive (we're talking less than 10,000
> simultaneous connections). Long-polling servers tend to use non-
> blocking IO, so you'd need to write something using java.nio.
>
> This means you'd have to drop Ring compatibility and Java servlet
> compatibility.
>
> Next you'd need to design your framework around a streaming, event-
> based model. In a resource-based model, you need one function that
> takes in a request and returns a response. An event-based model is
> obviously more complex, as you need to be able to assign many
> functions to various events, such as connection, disconnection, data
> received, etc. This would be tying yourself to a single Java HTTP
> server, or writing your own.

I'm not convinced that it would be all that more difficult to write an
event-based web server that would handle typical request/response
cycles and long-lasting connections equally well. Yes, you'd probably
have to give up the servlet API and definitely the one-thread-per-
connection model, but IMO both are mistakes anyway. AFAIK there's no
clojure-based event system right now, but one could probably be
written, and I suspect it could work pretty well even if you'd
probably have to take more care about how to handle your state; though
"typical functional" clojure's is pretty close to what you'd need,
there's some nooks and crannies that don't seem to support event-
based, multiple-interleaved-actions-in-a-single-thread much - like the
ref-type synchronization mechanisms, which all seem to assume that
each task/transaction runs in its own thread. Still, I think for a
network server, you don't really need all that much shared state
anyway.

As for compojure, there's two things that currently make this kind of
scheme an uneasy match:

One is the use of dynamic variables (*errors* and *params* are the two
that stand out most) - but I'm already writing my code to keep the use
of them to a minimum, and I think it wouldn't be too hard to get rid
of them completely with only minimal extra code and a couple of useful
macros.

The other is the aforementioned lack (in both Java and clojure) of a
generic event framework for web servers, meaning it would probably be
hard to port from one server to the next (although I don't think there
even are all that many event-based webservers for Java, and personally
I don't really care that much about portability anyway if I can get a
single good server to work with). If you're willing to submit to a
single implementation for the time being, I think many of the features
in compojure could be kept intact or would only need minimal changes,
since most of it pretty much functional anyway, but the core request/
response "simple function call" interface would have to go in favor of
some kind of event/callback mechanism.

If all this comes across as condescending to compojure, I want to
assure all of you that wasn't my intention. As a matter of fact I'm
working on a compojure-based project right now and it's the most fun
I've had in a year. :)

As an aside, http://mina.apache.org/ looks sort of interesting to me,
though I've not researched it much yet.

Cheers,
Joost Diepenmaat.

[James Reeves]

On Dec 10, 10:44 pm, Joost <jo...@zeekat.nl> wrote:
> I'm not convinced that it would be all that more difficult to write an
> event-based web server that would handle typical request/response
> cycles and long-lasting connections equally well. Yes, you'd probably
> have to give up the servlet API and definitely the one-thread-per-
> connection model, but IMO both are mistakes anyway.

It's certainly possible to design an event-based web server, and
Clojure is a good language to do it in. However, in order to do so you
need to sacrifice compatibility (with Ring and Java Servlets) and
simplicity (as an event-based model is necessarily more complex than a
request-in-response-out model).

That's not to say an event-based web server is a bad idea; far from
it. But I do think that a framework based around binding RESTful
resources to URLs has a quite different focus to a framework based
around handling events from HTTP clients.

However, perhaps I'm wrong. Part of the reason why I'm factoring many
parts of Compojure out into individual libraries (like Hiccup and
Clout) is to make it easier for people to build their own frameworks
and follow the designs they think are best. If you wish to build an
event-based web server, please feel free to take any code from
Compojure or its satellite libraries if it makes your job any easier.

> If all this comes across as condescending to compojure, I want to
> assure all of you that wasn't my intention. As a matter of fact I'm
> working on a compojure-based project right now and it's the most fun
> I've had in a year. :)

That's good to hear :)

- James

[Adrian Cuthbertson]

>As an aside, http://mina.apache.org/ looks sort of interesting to me,
>though I've not researched it much yet.

Also check out Netty - www.jboss.org/netty/

-Rgds, Adrian

[Shantanu Kumar]

Yes, Netty appears to be a better fit for this thing. Especially, this may be useful:

http://www.jboss.org/file-access/default/members/netty/freezone/guide/3.1/html/architecture.html#d0e2108

Regards,

Shantanu 

[Shantanu Kumar]

Yet another interesting project to look at might be this: http://www.simpleframework.org/

It doesn't use a one-thread per request model.

Regards,

Shantanu

[Shantanu Kumar]

Final JSR 315 (Servlet 3.0 spec) is being released: http://jcp.org/en/jsr/detail?id=315

Example code is here (notice the Chat application): http://blogs.sun.com/enterprisetechtips/entry/asynchronous_support_in_servlet_3

I hope Servlet 3.0 Async support will help the cause we are discussing in this thread. GlassFish 3 already has the reference implementation it seems. So it's only a matter of time until Tomcat and Jetty get those.

Regards,

Shantanu

[Nipun]

I have used continuations from compojure and experienced the same
problem
(for some reason the continuations handling code is not in the
distribution so had to write my own)
but I could not find a way to know if a client has disconnected.