Liferay 4.2 reverse ajax探索

为了使用Liferay中的chat功能，除了要建立一台jabber server之外，还需要启动两个属性
jabber.xmpp.server.enabled=true
reverse.ajax.enabled=true

jabber.xmpp.server.enabled比较好理解，reverse.ajax.enabled是什么？

在Liferay 4.2的chat有个特点。即使用户没有chat portlet的权限，当有其他人员向其发送chat消息时，会立即弹出一个chat消息框。

该消息框的实现就是用了reverse ajax。我们可以trace一下liferay的代码看看这个自动弹出的chatbox是如何实现的。

首先找到ajax.js
找到里面有

request: function() {
...
onComplete: ReverseAjax.response,
...
},

response: function(xmlHttpRequest) {
...
ReverseAjax.request();
...
},

写过点ajax的朋友都能猜出来，这两段是干什么的。一旦一个ajax请求发起，如果正常结束，那么在responnse方法中重新再发起一次请求。

吓人一跳，liferay不会那么没效率吧，当中都没有个延迟？？

再找java代码ReverseAjaxAction.java 在不起眼的代码中，有这么一行
reqWait.waitForRequest();看看waitForRequest的定义

public synchronized void waitForRequest() throws InterruptedException {
int heartbeatCycle = GetterUtil.getInteger(PropsUtil.get(
PropsUtil.REVERSE_AJAX_HEARTBEAT));

_timedOut = true;

wait(heartbeatCycle);
}

大有玄机！！找找notify是被谁调用的代码......
BinGo!!
RosterUpdateListener和MessageListener中有reqWait.notifyWait()

让我们重新理一下思路
两条主线
ajax.js中ReverseAjax.request()->ReverseAjaxAction.java->reqWait.waitForRequest()
RosterUpdateListener|MessageListener->reqWait.notifyWait()

在浏览器中一直有一个请求，但是当请求到服务端端时，被java阻塞了。
当有jabber消息返回时，则会notify前一个被阻塞的线程，最终使得浏览器端的ajax代码将chatbox显示出来。

最终，我们得出一个结论，liferay 中ReverseAjax是用poll来模拟push。但是poll过程中利用了java线程同步的技巧。

当然以上的分析还很粗糙。没有解释线程同步之间的资源和超时的设计，本文就算起个抛砖引玉的作用吧。

分析的不错 
"当有jabber消息返回时，则会notify前一个被阻塞的线程" 这句能具体解释一下吗，谢谢

ReverseAjax.request()难道不会超时么？
这样不断的访问服务器效率有问题吧

re lyo:
在浏览器中一直有一个请求，但是当请求到服务端端时，被java阻塞了。随后这个线程一直在wait状态。

之后当jabber的线程获得一个消息，则会调用RosterUpdateListener或者MessageListener，这两个Listener会调用notifyWait，这个notifyWait会解除浏览器请求的线程的阻塞。

re chenqj:
ReverseAjax.request()有超时。
在http环境下，除了"不断的访问服务器"还有其他方法么？

多谢回复！ 等于说liferay也没有解决客户端不停的向服务器发送请求的问题，服务器的访问量仍然是很大的。 不过看 gmail的talk实现应该有其他方法，否则google的服务器撑不住的。

从网上找到的少得可怜的资料看，gmail talk也是类似的实现
http://www.cnblogs.com/cathsfz/archive/2006/10/22/536454.html
Liferay同传统web chat相比的一个改进是在与服务端会把一次数据请求先block一段时间。如果这段时间内有数据，则马上返回，如果没数据则等待到超时后再返回。

这样做的好处是避免客户端的快速请求，因为每次空数据都会被block一段时间。这样降低了客户端和服务器的一部分资源。但是问题是单次请求所占服务器端口的时间较长，单服务器并发的用户数不能过大。不过web chat都会占用大量端口，区别在于每次请求的占用时间。即使单次时间短，如果请求非常频繁，并发用户数也大不了哪去。


说实话，我觉得在http协议下要模拟服务器的推模型几乎没有什么更好的方法了。

至于Google，火星人都知道他是一个服务器群。你要是硬件投资上去，Liferay也可以做成集群的。