One minor follow on comment. If you implement streaming, you should implement long-polling as well because there are broken HTTP proxies in the wild that will buffer responses rather than streaming them through directly. You want a non-blocking alternative for clients behind them to fallback to. Also, with streaming you do not want to deploy with Apache in front of your app server. Their connector incorrectly buffers streamed responses.
Seth From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of aduston1976 Sent: Friday, June 13, 2008 11:41 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Non-Blocking IO and BlazeDS Streaming Seth, Thank you very much for your thoughtful and very complete message. Is anyone else out there working on a Tomcat CometProcessor-based streaming implementation? I foresee about 2k LOC standing between the current code and one that includes an endpoint that can be used with a CometProcessor implementor. If you're already working on such an implementation or if you would like to, then let's please talk over Google Talk or whatever. I am [EMAIL PROTECTED] on Google Talk. Since BlazeDS already includes functionality to route messages across clusters, this would turn it into the server I've been looking for. Adam --- In flexcoders@yahoogroups.com, "Seth Hodgson" <[EMAIL PROTECTED]> wrote: > > Hi Adam, > > > > Adobe is not working on this, although I'd encourage the community to. > > Here's why we're not. > > > > 1. We're participating in the Servlet 3 JSR which will add async > IO support to the Servlet API (in the form of suspendable/resumable > requests). Once that API is finalized you can expect official support > for it in BlazeDS. > > 2. The CometProcessor API in Tomcat and the pre-final version of > suspendable requests in Jetty are not standard APIs - they'll be > superceeded by what makes it into the official Servlet 3 spec, making > official Adobe support for these non-standard APIs a dead end. > > 3. We provide NIO-based HTTP endpoints that support both streaming > and long polling in LCDS 2.6 and scale into the 10s of thousands of > concurrent connections. These endpoints share their underlying plumbing > with our existing RTMP endpoint. This works in any servlet container, > not just Jetty or Tomcat, making it consistently useful to all our > customers and affording us the ability to tune it directly. > > > > That said, I'll reiterate that the community is encouraged to build > custom long-polling or streaming endpoints on top of the non-standard > Tomcat and Jetty APIs. Someone should take the lead on organizing the > community effort, and coordinating it. There's no sense in having ten of > you out there working on ten versions of the same thing J One thing > you'll need to be aware of is that for threadless long-polling support > you can't rely on the JVM saving the current Thread's execution stack > for you on a wait() and resuming later via a notify(); you actually need > to save off the request processing state yourself in order to resume it > later. To help out with this, I moved our suspendable AMF filter classes > into the BlazeDS codebase so you guys should use that rather than the > existing AMF filter classes that cannot be suspended/resumed; they're in > the same package: flex.messaging.endpoints.amf. > > > > Good luck and keep me posted, > Seth > > > > From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On > Behalf Of aduston1976 > Sent: Friday, June 13, 2008 9:21 AM > To: flexcoders@yahoogroups.com > Subject: [flexcoders] Non-Blocking IO and BlazeDS Streaming > > > > I need to push data to Flex clients, and I need more than 400 clients > to connect to each host. Even though I'm using BlazeDS for RPC, I was > thinking of using the XIFF XMPP library with a jabber server for > pushing data to clients, since streaming in BlazeDS uses blocking IO. > But, looking at the relevant classes in flex.messaging, > flex.messaging.endpoints, and flex.messaging.client in BlazeDS, I see > that it might not be too difficult to create a new servlet that > implements org.apache.catalina.CometProcessor and a new > BaseHTTPEndpoint subclass that can support multiple connections for > each thread. Such an implementation would be able to support over 10K > simultaneous streaming connections per host. > > Is there anyone else who's working on this, or interested in working > on it? Is Adobe already on the case, making this a waste of time? Any > thoughts or suggestions are appreciated. > > Adam >
