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
<<~WRD000.jpg>>
<<image001.jpg>>
<<image002.jpg>>
