|
去年的一个项目中,我设计了一个多线程的UDP通讯程式,由我方一台主机,分别对应四地发送接收数据包。 在生产环境已经非常稳健的运行了1年。 最近,随着业务的增加,连接的远端增加到了12个,也就是一个IP向12个IP发送接收数据包。 我在主线程中,管理这12个独立的通讯线程,互不干扰,由于服务器是2U4核,所以该程式的设计具有一定可伸缩性。 但是,最近维护人员告诉,发现会发生某地业务停顿。一检查,线程exception terminate。居然报的是:port already bind这个最常见的exception。但是在console里面,重启这个线程,它又可以正常启动,并稳定的运行。而且它每次发生的几率很随机,有时候死掉1个,有时死掉3个,或者全部正常。 去年,该程式做过多次压力测试,并没发现这个问题,现在唯一导致它发生的原因就是线程增加了3倍。 仔细分析,发现多线程的启动方式,是在spring里面进行管理和注册jmx,每个线程都事先配置成mbean。启动的时候,注入一个map里,再循环启动。而udp通讯的方式是,随机的由OS分配端口,会不会是线程的request太快,而OS没有lock port cache的strategy,我想到这里于是在循环启动bean的方法里面,加了一个Thread.sleep(100)。再次测试,解决。 最后,我认为os在分配随机端口的时候,可能没有锁定机制,如果线程的request是高conconrent,就有可能出现重叠,而引发port lready bind 这个最简单的错误。要解决这个问题,第一就是尽量延长启动间隔,尤其是多路并发的server上,第二,人为的控制port的分配。
|
作者:未知 | 文章来源:未知 | 更新时间:2008-1-15 16:39:39
|
|
|
|
最新文章 |
|
|
|