Anatole, Wow, this is great news. Thanks for letting everyone know. I wish I could make it to NY for your presentation, but I'll be stuck here in Chicago.
> 19th (http://www.eventbrite.com/event/126384018). Open source version should > be available at OReily in the Rough Cuts code section of our new Does this imply that there is a closed-source version available now? If so, I don't see anything about it on your blog. Adam --- In flexcoders@yahoogroups.com, "Anatole Tartakovsky" <[EMAIL PROTECTED]> wrote: > > Adam, > We completed Servlet 3 implementation of BlazeDS streaming - so you can > scale your push servers as much as you need to. There is a bit of testing > and revamped samples that need to be added, but Adobe "samples" app works > without any changes on the Flex side. > > I will be showing Jetty implementation at Flex Symposium in NYC on August > 19th (http://www.eventbrite.com/event/126384018). Open source version should > be available at OReily in the Rough Cuts code section of our new book in > September/August. Some QoS pieces and streamlined DataServices > implementation will be available around that timeframe as well. > Hope this helps, > Anatole Tartakovsky > Farata Systems > > > > > On Fri, Jun 13, 2008 at 5:11 PM, aduston1976 <[EMAIL PROTECTED]> wrote: > > > 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 flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com>, "Anatole > > Tartakovsky" > > > > <anatole.tartakovsky@> 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 <aduston@> 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 flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com><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: flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com><flexcoders% > > 40yahoogroups.com> > > [mailto: > > > > flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com> <flexcoders% > > 40yahoogroups.com>] On > > > > > Behalf Of aduston1976 > > > > > Sent: Friday, June 13, 2008 9:21 AM > > > > > To: flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com><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 > > > > > > > > > > > > > > > > > > > > > > > > > > >
