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