为什么消息队列会满了呢？

peakzhang

我碰见一个很奇怪的问题。
系统环境：windows 2003 中文企业版 ACE: 5.5版本 NT Service程序
系统结构：处理UDP消息，采用ACE_Proactor框架，在收到UDP消息后，把消息送入消息队列中，消息队列会逐个异步处理消息。
故障现象：初始时候完全正常，在过了大概2天后，系统出现故障，出现的问题log记录：
udp::handle_input_msg put msg error,error code:10035,queue state:1,full state:1, return -1.
message queue bytes:102403296,count:24807,length:864487.

队列满了。无法推入处理，可是不知道队列发生了什么事情。队列也是活动状态的，难道是队列中的消息处理，导致队列死锁？

如果有人有思路解决或者遇见过，请给与指教。

peakzhang

是不是你提取消息的速度比推入消息的速度略慢，时间长了就出现了这种状况

可以试着把高低水位变小，在短时间内来看会不会出现这种情况。。。

peakzhang

嗯。你说的没错。应该是svc里面的处理阻塞或者死锁了，造成数据不处理，但是我在往task里面put的时候，如果发现错误，就调用task的queue，flush(),清除里面的数据，可是发现无法清除。
我再跟踪一下看看。

peakzhang

这个问题很有代表性，我要做的一个应用也要求，能处理爆发的客户，我的基本想法使用一个消息队列，当队列满了时全部刷新到磁盘上，但这样也带来了一些问题，什么时候处理磁盘中的消息呢？当getq时队列空，在读文件？还一个很重要的问题，消息是不允许丢失的，那么这样是不是应该有个高效的持久机制？不知各位有啥看法？

   我相信这样的问题，大家几乎都碰到了，或者将来是要碰到的，那为什么不一起出个解决方案呢？

peakzhang

队列满了，是可以判断到的，但是是否能够处理，则看条件了。
我觉得持久化是个办法。

peakzhang

我的做法是尽量让GETQ的速度大于等于PUTQ，如果GETQ后处理消息的速度比较费CPU那就单开一个线程去处理，或生成多个GETQ线程做处理；持久化是个办法，但是实现起来比较麻烦。。。

peakzhang

持久化是个办法, depends on  your  application.

1.RT transient data has to be processed right away.
2.SEMI-RT transient data could be delayed in certain time-frame.
3.NON-RT (Is data has to been sinked or not)
also take a look of thread about MQ.

peakzhang

真正的答案：
是线程处理程序死锁造成的。不再处理信息了。