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 >
