GWT / Comet：有什么经验吗？

发布于 2024-07-14 19:41:36 字数 500 浏览 1 评论 0原文

有没有办法从 GWT“订阅”JSON 对象流并监听保持活动连接上的传入事件，而无需尝试一次获取所有事件？我相信这项技术的流行词是“Comet”。

假设我有 HTTP 服务，它打开保持活动连接，并将带有传入股票报价的 JSON 对象实时放入其中：

{"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"}
...

我需要监听此事件并实时更新 GWT 组件（表、标签）。有什么想法如何去做吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

是你 2024-07-21 19:41:36

StreamHub 有一个 GWT Comet 模块：

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

StreamHub 是一个具有免费社区版的 Comet 服务器。这里有一个实际的示例。

您需要下载 StreamHub Comet 服务器并创建一个新的 SubscriptionListener，使用 StockDemo 示例作为起点，然后创建一个新的 JsonPayload 来流式传输数据：

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

从 google code 站点下载 JAR，将其添加到您的 GWT 项目中类路径并将包含添加到您的 GWT 模块：

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

连接并订阅您的 GWT 代码：

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);
...

然后在更新侦听器中按照您喜欢的方式处理更新（也在 GWT 代码中）：

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;
          ...
      }
}

不要忘记在您的 GWT 中包含streamhub-min.js GWT 项目主要 HTML 页面。

There is a GWT Comet Module for StreamHub:

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

StreamHub is a Comet server with a free community edition. There is an example of it in action here.

You'll need to download the StreamHub Comet server and create a new SubscriptionListener, use the StockDemo example as a starting point, then create a new JsonPayload to stream the 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 projects classpath and add the include to your GWT module:

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

Connect and subscribe from 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 how 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;
          ...
      }
}

Don't forget to include streamhub-min.js in your GWT projects main HTML page.

回复收藏 0 原文

终难遇 2024-07-21 19:41:36

我已经在几个项目中使用了这种技术，尽管它确实存在问题。我应该指出，我只是通过 GWT-RPC 专门完成了此操作，但无论您使用什么机制来处理数据，其原理都是相同的。根据您具体在做什么，可能没有必要让事情变得过于复杂。

首先，在客户端，我不相信 GWT 能够正确支持任何类型的流数据。在客户端可以实际处理数据之前，连接必须关闭。从服务器推送的角度来看，这意味着您的客户端将连接到服务器并阻塞，直到数据可用为止，此时它将返回。无论在已完成的连接上执行什么代码，都应立即重新打开与服务器的新连接以等待更多数据。

从服务器端来看，您只需进入等待周期（java 并发包对于具有块和超时的情况特别方便），直到有新数据可用。那时，服务器可以将数据包返回给客户端，客户端将进行相应更新。根据数据流的情况，需要考虑很多因素，但这里有一些需要考虑的因素：

客户端获得的每一次更新都很重要吗？如果是这样，那么服务器需要缓存客户端获取一些数据然后重新连接之间的任何潜在事件。
会有大量更新吗？如果是这种情况，打包多个更新并每隔几秒一次下推一些块可能比让客户端一次获取一个更新更明智。
服务器可能需要一种方法来检测客户端是否已经离开，以避免为该客户端堆积大量的缓存包。

我发现服务器推送方法存在两个问题。对于大量客户端，这意味着 Web 服务器上有大量开放连接。根据相关的 Web 服务器，这可能意味着要创建大量线程并保持打开状态。第二个与典型浏览器每个域 2 个请求的限制有关。如果您能够从二级域提供图像、CSS 和其他静态内容，则可以缓解此问题。

I have used this technique in a couple of projects, though it does have it's problems. I should note that I have only done this specifically through GWT-RPC, but the principle is the same for whatever mechanism you are using to handle data. Depending on what exactly you are doing, there might not be much need to over complicate things.

First off, on the client side, I do not believe that GWT can properly support any sort of streaming data. The connection has to close before the client can actually process the data. What this means from a server-push standpoint is that your client will connect to the server and block until data is available at which point it will return. Whatever code executes on the completed connection should immediately re-open a new connection with the server to wait for more data.

From the server side of things, you simply drop into a wait cycle (the java concurrent package is particularly handy for this with blocks and timeouts), until new data is available. At that point in time, the server can return a package of data down to the client which will update accordingly. There are a bunch of considerations depending on what your data flow is like, but here are a few to think about:

Is a client getting every single update important? If so, then the server needs to cache any potential events between the time the client gets some data and then reconnects.
Are there going to be gobs of updates? If this is the case, it might be wiser to package up a number of updates and push down chunks at a time every several seconds rather than having the client get one update at a time.
The server will likely need a way to detect if a client has gone away to avoid piling up huge amounts of cached packages for that client.

I found there were two problems with the server push approach. With lots of clients, this means lots of open connections on the web server. Depending on the web server in question, this could mean lots of threads being created and held open. The second has to do with the typical browser's limit of 2 requests per domain. If you are able to serve your images, css and other static content fro second level domains, this problem can be mitigated.

回复收藏 0 原文

十二 2024-07-21 19:41:36

gwt 确实有一个类似 cometd 的库 - http://code.google.com/p/ gwteventservice/

但我没有亲自使用过它，所以不能真正保证它是否好，但 doco 看起来相当不错。值得一试。

我还见过其他一些库，例如 gwt-rocket 的 cometd 库。

回复收藏 0 原文

我不吻晚风 2024-07-21 19:41:36

可以在此处... 找到 GWT 的 Comet 实现的一些初步想法...是否有更成熟的东西。

回复收藏 0 原文

一笑百媚生 2024-07-21 19:41:36

此外，那里还提供了有关 GWT/Comet 集成的一些见解，使用更多的剪切 -和尖端技术：“Jetty Continuations”。值得一看。

回复收藏 0 原文

千仐 2024-07-21 19:41:36

在这里您可以找到说明（带有一些源示例）了解如何为 IBM WebSphere Application Server 执行此操作。与 Jetty 或任何其他支持 Comet 的 J2EE 服务器应该没有太大不同。简而言之，这个想法是：通过 GWT RPC 将 Java 对象编码为 JSON 字符串，然后使用 cometd 将其发送到客户端，Dojo 接收该对象，触发您的 JSNI 代码，该代码调用您的小部件方法，在其中反序列化该对象再次使用 GWT RPC。瞧！ :)

我对这个设置的体验是积极的，除了安全问题之外没有任何问题。在这种情况下，目前还不清楚如何实现 Comet 的安全性...似乎 Comet 更新 servlet 应该具有不同的 URL，然后可以应用 J2EE 安全性。

回复收藏 0 原文