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-...@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
[email protected]
_______________________________________________
rap-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/rap-dev
