Re: [flexcoders] Re: Non-Blocking IO and BlazeDS Streaming
Norbert, I am finishing chapter on Flex Networking for new OReily book this month. It should be available on rough cuts mid/end of next month and will include jar, installation instructions and sample code . Thank you, Anatole On Mon, Sep 15, 2008 at 3:19 PM, nkopcsek [EMAIL PROTECTED] wrote: 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 flexcoders%40yahoogroups.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.comflexcoders% 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.comflexcoders% 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
Re: [flexcoders] Re: Non-Blocking IO and BlazeDS Streaming
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 [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.comflexcoders% 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.comflexcoders% 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
Re: [flexcoders] Re: Non-Blocking IO and BlazeDS Streaming
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.comflexcoders% 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
RE: [flexcoders] Re: Non-Blocking IO and BlazeDS Streaming
One minor follow on comment. If you implement streaming, you should implement long-polling as well because there are broken HTTP proxies in the wild that will buffer responses rather than streaming them through directly. You want a non-blocking alternative for clients behind them to fallback to. Also, with streaming you do not want to deploy with Apache in front of your app server. Their connector incorrectly buffers streamed responses. Seth From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of aduston1976 Sent: Friday, June 13, 2008 11:41 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Non-Blocking IO and BlazeDS Streaming 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, 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: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of aduston1976 Sent: Friday, June 13, 2008 9:21 AM To: flexcoders@yahoogroups.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
Re: [flexcoders] Re: Non-Blocking IO and BlazeDS Streaming
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, 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: flexcoders@yahoogroups.com flexcoders%40yahoogroups.com [mailto: flexcoders@yahoogroups.com flexcoders%40yahoogroups.com] On Behalf Of aduston1976 Sent: Friday, June 13, 2008 9:21 AM To: flexcoders@yahoogroups.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
