Hi Anatole, being also interested in a NIO endpoint for BlazeDS, I'm wondering if your implementation is already available to the public.
Greetings, Norbert --- In flexcoders@yahoogroups.com, "Anatole Tartakovsky" <[EMAIL PROTECTED]> wrote: > > Adam, > We are setting different server this week with jetty for sample push apps - > should post availability either in my or Yakov's blog. > We will rehost Coenraets collaboration apps, Flex "sample" one as well as > few financial samples of our own - > do not know if you have another use case that you think is interesting. > > The version stays closed source till it is published - but will be available > on Web 8/19. > > Thank you > Anatole > > > On Wed, Jul 16, 2008 at 1:10 AM, aduston1976 <[EMAIL PROTECTED]> wrote: > > > 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 <flexcoders%40yahoogroups.com>, "Anatole > > Tartakovsky" > > <anatole.tartakovsky@> 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 <aduston@> 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><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><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><flexcoders% > > > > 40yahoogroups.com> > > > > [mailto: > > > > > > flexcoders@yahoogroups.com <flexcoders%40yahoogroups.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><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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
