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"
>
> <[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 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
> > > >
> > >
> > >
> > >
> >
>
>
>
