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" <[EMAIL PROTECTED]> 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
> >
>
>
>
