Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Async-Methods

Hmm, I just realized that what I wanted to use async-methods for won't probably work. May be you can help me with that problem as well. 

Basically I have a host providing a service with a long running method and a client using this service. Async-methods will help me to avoid time out exceptions but what I also would like to do is sending progress update events while the long running method is executed. I primarily wanted to (mis)use async-methods in a way like this: 

public ProgressUpdateEvent myLongRunningMethod(Parameter someParams, IAsyncCallback<ProgressUpdateEvent> callBack){
callBack.onSuccess(new  ProgressUpdateEvent(...));

callBack.onSuccess(new ProgressUpdateEvent(finished));

But as I understand the ServiceImpl doesn't have to implement the async-method hence I won't get an IAsyncCallback-object in my hands. What would be a good solution to send progress events while executing long running methods?


Am 22.11.2010 um 17:32 schrieb Scott Lewis:

Hi Eugen and all,

As Markus correctly indicated, it's not necessary to create a second service registration for asynchronous remote access.  For everyone's reference, there is some example code and preliminary explanation of the asynchronous remote services support here [1].

All that's necessary for consumers to use the asynchronous support to declare a well-formed <service>Async interface...e.g. like Eugen has done with IExampleServiceAsync (Markus is correct that currently it must be in same package and bundle as the IExampleService).   And Markus is also quite right that if the original service method is (e.g.):

public String getName();

then the correct form for the asynchronous callback method is:

public void getNameAsync(IAsyncCallback<String> callback);

Alternatively if the original form for the method has parameters...e.g.

public String getName(String param);

Then the async callback form would be:

public void getNameAsync(String param, IAsyncCallback<String> callback);

The general rule for the IAsyncCallback is that it is assumed to be the last parameter...i.e. after any existing ones.

Note also that there are *two* forms supported for async method access...the IAsyncCallback is one, and IFuture is the for example the IExampleServiceAsync can also have:

public IFuture getNameAsync();

This doesn't have to be present in the IExampleServiceAsync interace, however.  But if either form or both are present, they can be used.

Note that the returned type of IFuture.get() will be the same as the return value for getName() in the original service interface (String in this case).  I'm trying to get the addition of generics to the graduated concurrent API [2] (I'm the author/contributor of the Equinox concurrent API...but I need to get the Equinox committers to actually apply the desired changes...thus the bug [2]).  With a graduated concurrent API, one would be able to write declarations like this:

IFuture<String> getNameAsync();

and call

String result = future.get();

I think this would make the IFuture a little more usable/more accessible.

There is also some blog postings by me about asynchronous remote services [3] (which is cool if you ask me).  More docs and examples are certainly needed...please join and contribute to the ECF documentation project [4].

One final thing...I've started but not yet completed an Eclipse plugin that uses annotations to automatically create the <service>Async interface.  For example, you could do something like this:

public interface IExampleService {

public String getName();


and Eclipse and the java6 annotation processor would/will create the IExampleService async class (and all methods) for you.  The bundle is in the incubation area here [5].  If others would like to contribute to this annotation processor please open an enhancement request and we'll coordinate on finishing it (what's there barely works).



ecf-dev mailing list

Back to the top