Anatole, thank you sincerely for your message. I've always admired the Farata Systems blog posts and I will email you offline.
Has anyone else taken a stab at this? Does anyone else have any thoughts about it? Thanks again, Adam --- In [email protected], "Anatole Tartakovsky" <[EMAIL PROTECTED]> wrote: > > Adam, > 400 concurrent users is very low number - you might conside freee > express LCDS 2.6 in single multicore CPU version to support that. Adobe > creates standalone socket server (that you can place on the same servers > port 80 with separate host name within domain/tcp address). Then you would > get RTMP class functionality transparently working under HTTP wrapping. > > We did Tomcat implementation - however we encountered reliablity issues > in the base software and do not recommend it unless you build recoverability > stack that in our experience is very app specific. Also, you need > significant framework on the client as unlike RTMP solution as you have to > minimize number of subscriptions to 1 due to limit on number of HTTP > connections. Jetty implementation is better and more close to Servlet > 3/JSR-315 spec, but is would be waste of time at this point given the size > of the users group. > > Given the current state and availability of free LCDS 2.6 we were spending > more time on client-side components that mimic DataService object including > server push. Main goals are maintaing minimum requirements on connectivity > and actual channel implementation and provide application support for common > tasks and robustness/QoS. > > You can mail me directly at atartakovskyatfaratasystemsdotcom id you have > any questions > > Sincerely, > Anatole Tartakovsky > > > > On Fri, Jun 13, 2008 at 2:41 PM, aduston1976 <[EMAIL PROTECTED]> wrote: > > > 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 [email protected] <flexcoders%40yahoogroups.com>, "Seth > > Hodgson" <shodgson@> 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: [email protected] <flexcoders%40yahoogroups.com> [mailto: > > [email protected] <flexcoders%40yahoogroups.com>] On > > > Behalf Of aduston1976 > > > Sent: Friday, June 13, 2008 9:21 AM > > > To: [email protected] <flexcoders%40yahoogroups.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 > > > > > > > > > >
