GWT / Comet: any experience?

Question

Is there a way to "subscribe" to a stream of GWT objects in JSON and listen for incoming events in "keep-alive" mode without trying to get them all at once? I think Comet is the buzzword for this technology.

Suppose I have an HTTP service that opens a keep-alive connection and places JSON objects with incoming stock quotes in real time:

{"symbol": "AAPL", "bid": "88.84", "ask":"88.86"}
{"symbol": "AAPL", "bid": "88.85", "ask":"88.87"}
{"symbol": "IBM", "bid": "87.48", "ask":"87.49"}
{"symbol": "GOOG", "bid": "305.64", "ask":"305.67"}
...

I need to listen to these events and update GWT components (tables, labels) in real time. Any ideas how to do this?

Answer 1

There is a GWT Comet module for StreamHub:

http://code.google.com/p/gwt-comet-streamhub/

StreamHub is a free comet server community. Here is an example of this in action here .

You will need to download the Comet StreamHub server and create a new SubscriptionListener, use the StockDemo example as a starting point, and then create a new JsonPayload for streaming data:

 Payload payload = new JsonPayload("AAPL"); payload.addField("bid", "88.84"); payload.addField("ask", "88.86"); server.publish("AAPL", payload); ... 

Download the JAR from the Google code site, add it to your GWT class path and add include to your GWT module:

 <inherits name="com.google.gwt.json.JSON" /> <inherits name="com.streamhub.StreamHubGWTAdapter" /> 

Connect and subscribe to your GWT code:

 StreamHubGWTAdapter streamhub = new StreamHubGWTAdapter(); streamhub.connect("http://localhost:7979/"); StreamHubGWTUpdateListener listener = new StockListener(); streamhub.subscribe("AAPL", listener); streamhub.subscribe("IBM", listener); streamhub.subscribe("GOOG", listener); ... 

Then process the updates as you like in the update listener (also in the GWT code):

 public class StockListener implements StreamHubGWTUpdateListener { public void onUpdate(String topic, JSONObject update) { String bid = ((JSONString)update.get("bid")).stringValue(); String ask = ((JSONString)update.get("ask")).stringValue(); String symbol = topic; ... } } 

Remember to include streamhub-min.js in the main HTML page of GWT projects.

Answer 2

I have used this technique in several projects, although it has problems. I should note that I did this specifically with GWT-RPC, but the principle is the same for any mechanism that you use to process data. Depending on what you are doing, it may not be necessary to complicate the situation too much.

First of all, on the client side, I do not think that GWT can correctly support any streaming data. The connection must be closed before the client can process the data. What this means from the point of view of the server is that your client will connect to the server and block until the data is available, and at what point it will return. No matter what code is executed in a completed connection, you must immediately reopen a new connection to the server in order to expect more data.

From the server side, you simply go into a wait loop (this requires the java concurrent package, which blocks locks and timeouts) until new data appears. At this point, the server can return the data packet to the client, which will be updated accordingly. Depending on how your data stream works, there are many considerations, but here are some things to think about:

• Is the client important for every update? If so, then the server needs to cache any potential events between the times when the client receives some data and then reconnects.
• Will there be update updates? If so, it would be wiser to pack a few updates and click the pieces at a time in a few seconds, and not to let the client receive one update at a time.
• The server will probably need a way to detect if the client has left to avoid piling up a huge amount of cached packets for this client.

I found that there is a problem with the approach to the server. With a large number of clients, this means many open connections on the web server. Depending on the web server in question, this may mean creating multiple threads and opening them. Secondly, this is a typical browser limit of 2 requests per domain. If you can serve your images, css and other static materials for second-level domains, this problem can be mitigated.

Answer 3

there really is a comet-like library for gwt - http://code.google.com/p/gwteventservice/

But I personally did not use it, so I can’t really vouch for whether this is good or not, but the doko seems to be good. worth a try.

Here are a few others I've seen, such as gwt-rocket cometd .

Answer 4

Some preliminary ideas for implementing a comet for GWT can be found here ... although I wonder if there is anything more mature.

Answer 5

In addition, some information on GWT / Comet integration is available there using even more cutting and percolation technologies: Continuations Jetty. Worth a look.

Answer 6

Here you can find a description (with some source examples) of how to do this for IBM WebSphere Application Server. It should not be too different from Jetty or any other C2-enabled J2EE server. In short, the idea is this: encode your Java object to a JSON string via GWT RPC, then use cometd to send it to the client where it will be received by Dojo, which runs your JSNI code, which calls your widget methods, where you deserialize the object again uses the GWT RPC. Voila! :)

My experience with this setting is positive, there were no problems with it, except for security issues. Actually, it’s not entirely clear how to implement comet security in this case ... It seems that servlets for Comet updates should have different URLs, and then you can apply J2EE protection.

Answer 7

The JBoss Errai project has a message bus that provides bidirectional messaging, which provides a good alternative to the comet.

Answer 8

We use Atmosphere Framewrok ( http://async-io.org/ ) for ServerPush / Comet in the GWT application.

On the client side, the Framework has GWT integration, which is quite simple. On the server side, a simple servlet is used.

We are currently using it in production with over 1000 compatible users in a cluster environment. We had some problems along the way that needed to be solved by changing the source of the atmosphere. Also the documentation is very thin.

The frame is free to use.