Pushlet的那些坑
博客专区 > lei.D 的博客 > 博客详情
Pushlet的那些坑
lei.D 发表于1年前
Pushlet的那些坑
  • 发表于 1年前
  • 阅读 80
  • 收藏 0
  • 点赞 0
  • 评论 0

腾讯云 技术升级10大核心产品年终让利>>>   

摘要: 如果你需要从服务器端向浏览器端推送消息,那么你可能会需要Pushlet。尤其是,不支持WebSocket的浏览器。当然,如果环境支持WebSocket,似乎可选的组件会更多一些。个人在项目中使用了Pushlet,在此分享一下其中的坑。

1. 服务器端推送组件

CometDPushletDWRAPE(Ajax Push Engine)

2. 软件环境

使用Pushlet完成服务器端的消息推送,实现群组IM。客户端模式为PULL,数据交换格式为XML-STRICT

3. 其中的坑

3.1 中文消息坑 

现象

中文消息丢失后,似乎整个系统都瘫痪了

跟踪调查

结合源代码跟踪调试发现,所有要发送的消息都基于Event对象,Event对象最终被转换为XML格式的字符串发送至客户端。而在toXML过程中,当遇到中文时程序进入异常处理过程,错误消息为“非ISO-8859-1字符”,该消息因为异常不再发送至客户端,消息丢失了。可恶的是,后台日志中并没有明显错误。

补救方法

将待发送的对象作为Event的data属性,将待发送对象转换为JSON格式的字符串,并转码。我在项目中使用的是UTF-8编码。

new String(JSONObject.fromObject(obj).toString().getBytes("UTF-8"),"ISO-8859-1");

虽然在控制台中输出是乱码的,实际测试发现,浏览器端UTF-8编码能够正确接收并显示中文。

3.2 配置文件

根据Pushlet.properties中的注释,个人修改了部分配置,结果消息丢失率很高。考虑到jar包不大,代码相对较少就读了一些关键类,如SessionManager,Session,Controller,Subscriber,Subscription等。总结一下结论如下:

A .SessionManager删除Session

当如下情况发送时

1. 当发送数据时,出现异常

2. 当Session的timetoLive<0。

3. 当Session的两次Refresh请求间隔,超过了配置的refresh.timeout

B. 关于Session是否过期的检查

通过如下手段实现

1.  每次客户端发送refresh请求,就会将Session的timeToLi ve重置为session.timeout.mins

2. 服务器端有1个AgeTask来定时检查Session的timeToLive,周期为1分钟。所以,配置文件中session.timeout的单位为分钟

3.  每次客户端发送refresh请求,等待时间主要受queue.read.timeout.millis影响。如果没有新消息到达,请求是在读取消息队列超时之后返回

C. 基于B的推理

1. pull.session.timeout 不能设置为1,最小值为2。因为设置为1意味着Session的timeToLive为1分钟,考虑到实际线程调度的问题,AgeTask的执行间隔可能会超过1分钟。当AgeTask对每个Session的TimeToLive减去执行间隔delta时,Session纷纷超时。于是,刚刚发送的群组消息,仅有少数几个群组用户可以正确接收。说没法送成功吧,有人接收到了消息。说发送成功吧,莫非程序也检查用户人品。

2. queue.read.timeout+ 必须远小于 pull.refresh.timeout。因为如果有消息到达,则请求会立刻返回,而后发送下一次请求。如果没有消息到达,则要一直等到timeout,结合A.1,如果下一次请求没有如期到达,则该Session将会被stop掉,进而被remove掉。

3. 此外在完成本次请求,开启下一次请求之前的间隔受pull.refresh.wait.min.millis和pull.refresh.wait.max.millis两个参数影响。通过读取代码发现,客户端会生成1个属于[min,max]的随机值作为请求等待时间,也会对refresh是否如期到达造成影响。本人使用中将两个值全部设置为0,实现下次请求的立刻执行。

从推理得出如下内容:

pull.session.timeout>=2

queue.read.timeout + random(pull.refresh.wait.min.millis,pull.refresh.wait.max.millis)+网络传输时间 < pull.refresh.timeout

同时,也证明,曾经发送成功的消息,确实是人品大爆发。按照推理修改了配置文件值如下:

listen.force.pull.all=true

pull.refresh.timeout.millis=10000

queue.read.timeout.millis=5000
queue.write.timeout.millis=300

pull.refresh.wait.min.millis=0
pull.refresh.wait.min.millis=0

3.3 与HttpSession关联

项目中有针对某个人发送消息的需求。所以,我们需要把PushletSession与HttpSession关联起来。这里要注意的是,我是直接关联的PushletSession对象本身。但SessionManager种经常会对Session进行克隆。结果就出现一种现象,关联的PushletSession已过期,但SessionManager中该Session依然active。其实,仅有Session的id是不变的,其对应的Session可能被clone多次,而与HttpSession关联的这一个,早已被SessionManager丢弃了。所以,仅使用与HttpSession关联的PushletSession的id,而不直接使用当前关联的PushletSession。

3.4 断线重连

客户端提供onError回调函数,我们可以在该函数中,进行断线重连。当然,如果是浏览器关闭,就没有必要了。

3.5 消息重发

    当Session被stop时,将Session中Subscriber中的EventQueue暂时恢复到HttpSession中。当新的Session重建OK时,优先发送这些缓存的消息。

    不过由于前后两个Session是没有关联的,在前1个Session stop之后,新的Session start之前,服务器端将无法向该用户推送消息。这个希望与诸位小伙伴讨论,欢迎拍砖!

 

共有 人打赏支持
粉丝 0
博文 3
码字总数 1828
×
lei.D
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: