Hi all,
I'm working on yet another multi-user chat-like application that requires server push. My team is currently evaluating technologies to use, and we love laszlo except for one thing:
Poor scalability of persistent connection.
Now as I understand it (please correct me if I'm wrong), the main bottleneck with persistent connection as implemented is the resources the persistent connection takes on the server. That is, the laszlo servlet keeps an http connection to the flash client alive, and proxies a call to a servlet or url that returns the actual results, maintaining a blocking connection and at least one servlet thread alive per user. There are a few workarounds I can think of, and I'll be happy to contribute any working code that comes out of this effort:
1. Rewrite the laszlo http connection servlet to use the continuation api available in jetty (http://docs.codehaus.org/display/JETTY/Continuations
). This, combined with the nio implemented in jetty, would effectively free connection and thread resources until a message is available to the user. Would this be a viable solution? If so, where is the entry point to a persistent http connection (the servlet), and how close to the chat application would using this continuation mechanism work?
2. I may do the above, but in stead of the agent mechanism/parameter user topics and integrate with ActiveMQ on the backend. Is there any existing work on integrating laszlo flash with a jms backend? If so would a more jms-native enhancement to lazslo connections be more useful than just modifying the above (a new adaptor like java-rpc)?
3. A third alternative is to modify the xml-rpc http connections. On the backend, the server would use the continuation api or something similar. However, given that, is it possible specify via lzx to make the http call, keep that connection open as long as possible while until a result comes back or there is a disconnect, and then immediately call the same method upon receipt of message or a disconnect. The idea would be that the threads are again not used on the server unless there is a message ready for the client. This is similar to the mechanism described by ActiveMQ (
http://www.activemq.org/site/ajax.html) under "Waiting Poll for Messages".
I'm wondering if pursuing these options would solve the scalability problems, and if not is there any work on making persistent connection more scalable?
Thank you for your time.
Best regards,
Chris
