Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rap-dev] Scalability Details and Server-side Push

Ralf,

I am Austin's colleague and we were discussing what problems we had with UICallbacks. I've slept since then so I'm having trouble remembering the exact details. What we were trying to do was start a UICallback in the RAP entry point and just let it run the entire session.

First, a little about our configuration. We are running with Apache as a front-end for both deployment and development. It serves up the static content and proxies requests to RAP. For deployment we run inside Tomcat using servletbridge. It's possible we were getting issues from timeouts somewhere along this chain. I'm not sure how Apache or Tomcat handle long-lived connections. I found some info on using Comet with Tomcat (http://tomcat.apache.org/tomcat-6.0-doc/aio.html), which looks like it would require support from the servletbridge. I know Jetty also supports Comet.

I'll have to do some testing and see if I can track down the exact problems.

Cole

Hi Austin, Stefan,

you seem to have a consensus that UICallbacks are problematic. Could you
explain this a bit more? Did you experience any concrete problems? Is it
scalability or are you concerned about the standing request? I think
that the "Comet" approach is rather common, isn't it?

I've seen a couple of use cases for permanent server-side push, so I'd
like to have a better idea where the limits of the UI callback are. Do
you have any ideas on how we could improve/optimize this functionality?

Thank you,
Ralf

Austin Riddle wrote:
> Hello Stefan,
> > In response to your questions: > > - How did you implement server-side push (you mentioned UICallbacks are
> not well suited where I fully agree).
> > We injected a polling loop into our custom clock widget that actually
> synchronized our client clock display with the server.  This took the
> form of some javascript in the custom widget that regularly initiates a
> request to the server. Since we could guarantee a request lifecycle at a
> certain interval, we could have the server post updates along with that
> client-initiated request.  In our dashboard application, it was
> imperative that it could just "sit" there and give status updates
> automatically. Nothing fancy:
> > _sendResponse : function(widget, field, value) {
>     if (!org_eclipse_rap_rwt_EventUtil_suspend) {
>         var wm = org.eclipse.swt.WidgetManager.getInstance();
>         var canvasId = wm.findIdByWidget(widget);
>         var req = org.eclipse.swt.Request.getInstance();
>         req.addParameter(canvasId + "." + field, value);
>         req.send();
>     }
> },
> > _onRefreshInterval : function(evt) {
>     this._sendResponse(this, "refresh", true);
> },
> > _startTimer : function() {
>     var interval = this.getRefreshInterval();
>     if (interval > 0) {
>         if (this._timer == null) {
>             this._timer = new qx.client.Timer(interval*1000);
>             this._timer.addEventListener("interval",
> this._onRefreshInterval, this);
>             this._timer.start();
>         } else {
>             this._timer.setInterval(interval);
>         }
>     }
>     else if (this._timer != null) {
>         this._timer.stop();
>     }
> }
> > - Did you really manage to run this app in IE6?
> With pain and suffering... mainly from the slooooooow javascript engine,
> and we had some real issues with the client-side memory footprint.
> Sometimes the app would top out at 500 MB client-side.  We also had an
> extreme number of script timeout warnings on load. Some of the things we
> did to address these issues is to use lazy content providers and also to
> load our components through the span of multiple client requests.  That
> was a nice trick that worked well.
> > - What are your findings concerning performance, users per server, etc?
> We have done some profiling on the server and our numbers indicate that
> we can support 500 users on a 32-bit Windows box.  We don't have any
> data thus far on the thread impact, but we are still investigating. So
> we are looking into virtualization options along with custom code to
> synchronize instances of the application.  We are somewhat constrained
> by the policies of the customer data centers.
> > I would be happy to answer any other questions. > > _______________________________________________
> rap-dev mailing list
> rap-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/rap-dev


--
Cole Markham

Computing and Information Technology
Texas Center for Applied Technology
Texas A&M University
(979) 458-7681
markhamc@xxxxxxxx



Back to the top