Eclipse Community Forums: Remote Application Platform (RAP) » Using UICallback for all Server Operations

Help

Home

Home » Eclipse Projects » Remote Application Platform (RAP) » Using UICallback for all Server Operations

Show: Today's Messages :: Show Polls :: Message Navigator

Using UICallback for all Server Operations [message #638198]

Wed, 10 November 2010 12:20

David Ellis

Messages: 15
Registered: September 2010

Junior Member

We are building a multi-user Eclipse RAP application, which will potentially have a large number of concurrent users.

Our architect would like all calls to the back-end database server to be made asynchronously, via message queues. When the user requests a function, such as "open record", rather than making a blocking call to the server, the application should send a message, and then an asynchronous message would come back containing the data to be displayed, and the record would open.

I have prototyped this using UICallback, and it appears to work OK. The callback is created when the menu operation is requested. The background thread sends the message to the server, and waits for the response message. It then notifies the UI to be updated via a Display.asyncExec() call.

This is based on the example at:

http://wiki.eclipse.org/RAP/FAQ#How_to_update_the_UI_from_a_ background_thread

So this appears to work., I just wonder if using UICallback in this way for all operations is good practice, or whether there are any pitfalls to this?

Thanks.

Report message to a moderator

Re: Using UICallback for all Server Operations [message #638221 is a reply to message #638198]

Wed, 10 November 2010 14:57

Cole Markham

Messages: 150
Registered: July 2009
Location: College Station, TX

Senior Member

David,

You might want to look at using the Job api for this use case. You can start a job which will wait for the background task to complete and then return to the user. The advantage is that you do not have any dependencies on RAP so that if you want to run your application as an RCP client it should work just as well. Also you get progress for the user (although you can disable this if you don't want it). Most importantly, RAP handles creating and releasing the UICallback so you don't have to manage it manually.

That said, Jobs only work for user-initiated updates. If you need timely updates from background tasks or actions by other users, then you need another solution. You can open a session-long UICallback, which we do but is not recommended by the RAP team. Or you can setup the client to poll at a frequent interval. We have a custom widget which does this because it is not built into RAP.

Hope that helps,

Cole

Report message to a moderator

Re: Using UICallback for all Server Operations [message #638245 is a reply to message #638221]

Wed, 10 November 2010 16:06

David Ellis

Messages: 15
Registered: September 2010

Junior Member

Cole,

Many thanks for that. I was aware of the Jobs API, but had not thought of using it here, for relatively quick operations, only for "slow" operations where a progress indicator was required. But I will have a look at that. If this works with RCP as well as RAP applications, that is certainly an advantage for us, as ideally we would like to target both platforms.

For "server push" type events, I had thought of using a session-long UI callback, which I think is the approach used by the "News Ticker" example which I found here:

http://www.devx.com/webdev/Article/36101/0/page/3

Cheers

David

Report message to a moderator

Re: Using UICallback for all Server Operations [message #639275 is a reply to message #638198]

Mon, 15 November 2010 20:48

Ralf Sternberg

Messages: 1313
Registered: July 2009

Senior Member

Hi David,

we usually do not recommend to enable the UICallBack globally. Reasons
are:

* Some proxies might cut connections after a period of inactivity. This
would break the UICallBack mechanism.

* The standing request prevents session timeouts as long as the browser
is open.

* The number of open connections to be handled by the servlet container
increases.

If these aren't issues for you, then I guess a global UICallBack is fine.

HTH, Ralf

On Wed, 10 Nov 2010 07:20:53 -0500, David Ellis wrote:

> We are building a multi-user Eclipse RAP application, which will
> potentially have a large number of concurrent users.
>
> Our architect would like all calls to the back-end database server to be
> made asynchronously, via message queues. When the user requests a
> function, such as "open record", rather than making a blocking call to
> the server, the application should send a message, and then an
> asynchronous message would come back containing the data to be
> displayed, and the record would open.
>
> I have prototyped this using UICallback, and it appears to work OK. The
> callback is created when the menu operation is requested. The background
> thread sends the message to the server, and waits for the response
> message. It then notifies the UI to be updated via a Display.asyncExec()
> call.
>
> This is based on the example at:
>
> http://wiki.eclipse.org/RAP/
FAQ#How_to_update_the_UI_from_a_background_thread
>
> So this appears to work., I just wonder if using UICallback in this way
> for all operations is good practice, or whether there are any pitfalls
> to this?

--
Ralf Sternberg

Need professional support for RAP and RCP?
http://www.eclipsesource.com/support/

Twitter: http://twitter.com/eclipsesource
Blog: http://www.eclipsesource.com/blogs/

Report message to a moderator

Previous Topic:	Inherit colors in Table (possibly List and Tree, too)
Next Topic:	Web Project with RAP

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Wed Apr 24 20:36:37 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter