Crude pushing with no selectors is relatively simple. You take open source of BlazeDS, find the piece that manages connection for streaming and migrate registration/"notifier.wait" part into custom endpoint/custom streaming servlet. From that point on everything is very much the same as Tomcat uses blocking IO for writing responses, so no extra coding is required compared to regular BlazeDS in Tomcat. The custom endpoint is a singleton class that implements synchronized map in place of named threads in the current blazeds implementation. Any java class in the same context can call endpoint class to push messages to the client - it prepares the package and calls the streaming servlet with the data and connection info. I do not believe that I can share actual code as it was written for a client and requires changes in basic BlazeDS code so it is not likely to make into OS version.
That unfortunately seems like temporary solution as J2EE Servlet 3.0 specification (JSR-315 http://jcp.org/aboutJava/communityprocess/edr/jsr315/index.html) did not favor Tomcat implementation and went with suspend/resume/compete API similar to Jetty. The Jetty version was a bit simpler as it allowed in place patching of BlazeDS and did not require so much code in streaming servlet. However it was left at prototype stage as client was more familiar with Tomcat. With Servlet 3 API, if you follow through BlazeDS code and again replace Threads registration with singleton with synchronized map for session management, it comes down to adding suspend, resume and complete calls to streaming servlet from BaseStreamingHTTPEndpoint. Instead of notify.wait loop you would need to add another header for "resume" and move the loop content into separate method called when the servlet resumes. Your Java code in the same context has access to endpoints static method like sendMessage(msg, user) and endpoint keeps and delivers our message when resumed. HTH, Anatole On Thu, Jun 5, 2008 at 6:22 PM, jfujita1 <[EMAIL PROTECTED]> wrote: > Converting BlazeDS to an NIO implementation is terribly interesting > for me. I'm building a GIS tracking app that will need to handle more > than a couple hundred connections. I knew that blocking IO code was > BlazeDS' bottleneck but a $20,000 LCDS license isn't in my company's > budget. I've heard that BlazeDS' messaging can scale via server > clustering and hardware multiplexing but I'm wondering if you have any > experience converting BlazeDS to NIO and if so if you were willing to > share how you did it. > > --- In [email protected] <flexcoders%40yahoogroups.com>, "Anatole > Tartakovsky" > > <[EMAIL PROTECTED]> wrote: > > > > It is 10 - please check the source of the BlazeDS source - can be > increased > > to few hundreds in your configuration but you might want to consider > setting > > process affinity and set up LCDS 2.6 express NIO HTTP adapter to really > > scale it up. Other option is to modify BlazeDS code to not keep the > > connection and enable NIO adapter on WebContainer/ move connection > > management into the custom endpoint - then you can scale blazeDS up > to few > > thousand connections.Regards, > > Anatole Tartakovsky > > > > On Thu, Jun 5, 2008 at 5:03 PM, Geoffrey <[EMAIL PROTECTED]> wrote: > > > > > I know there is a hardware imposed limitation to the number of > BlazeDS > > > real-time streaming connections that you can establish. I've heard > > > it's in the hundreds, so I'm trying to see how many I can connect to > > > my server(WinXP Pro 64-bit with two 3GHz Xeon CPUs and 8GB of RAM). > > > > > > Oddly enough after the 10th client logs in, all subsequent logins > > > revert to a polling connection. Is there some limit on the number of > > > streaming connections you can have before they fall back to polling? > > > Something else I'm missing? > > > > > > BTW, even with polling I can establish 200 connections and the server > > > barely blinks except for an increase in CPU usage due to all of that > > > polling. > > > > > > Thanks, > > > Geoff > > > > > > > > > > > > > >
