A cute recursive server push

[ewd_soul]

I'm using the following recursive way to have the server pushing data
into the browser.
It's very easy, but curiously I haven't found it in the documentation.

The idea is to do chained, or tail recursive, calls to the server.

Imagine to add this code to SchoolCalendarServiceImpl in the DynaTable
example:

int i = 0;
public String getString(String key) {
return key + " " + (i++);
}

and to add the getString function to the two interfaces too
(SchoolCalendarService and SchoolCalendarServiceAsync)

Then in SchoolCalendarWidget add somewhere this class:

class MyServer implements AsyncCallback {
public void onSuccess(Object result) {
webConsoleWidget.setStatusText( (String) result );
calService.getString("abc", this);
}

public void onFailure(Throwable caught) {
try {
throw caught;
} catch (Throwable e) {
GWT.log(e.toString(), null);
}
}
}

To start the chain, modify the onLoad method:

protected void onLoad() {
AsyncCallback asyn = new MyServer ();
calService.getString("abc", asyn);
dynaTable.refresh();
}

Now, on page load we place an async callback to getString and forget
it. When it will receive the string from the server, the
MyServer.onSuccess() will be called.
Here we print the string and place a second async callback, and so on.

This is a basic implementation. One could improve onSuccess to handle
the keep alive sent by the server. Say, if result is null then this is
a keep alive and we ignore it and simply call getString again. And on
the server side a java.util.Timer could answer to getString with null
if it has nothing to say by now.

I cant see any stack recursion. Am I right?

ewd_soul

[Joel Webber]

This is an excellent way to create the effect of 'pushing' data to the client.  And you're absolutely right that there is no stack recursion, because the callbacks are always invoked from the browser's event dispatching mechanism (in IE, for example, these events most likely come from the browser's window event pump).

The only caveats I would point out are:
- On the client, it consumes one connection to the server constantly.  Given that nearly all browsers implement a standard connection limit of 2 per host, you need to be aware of this when making other calls (if you're not careful, it's actually possible to create a deadlock situation if you think you're making two calls simultaneously but the browser serializes them).  This is a general problem with AJAX-style apps, and not limited to this solution in particular.
- On the server, you need to be aware that keeping a connection open all the time can consume an entire thread (depending upon your servlet container).  Often not a problem, but it can turn into a bottleneck.

joel.

[ewd_soul]

... but it seems to cause a memory leak on Firefox.

Well, I haven't yet investigated because I found it 10 minutes ago.
The first guilt is always my code, but on IE6 the memory leak doesn't
appear.

Could it be that report on the post "Potential bug/memory leak issue in
RemoteServiceServlet?" of march 23th?

I'll tell more on this when I'll investigate the problem. What I'm
doing is a lot of async callback, say 20 per second, on a jetty
container.

enrico