系统会向核心发送报文,但是核心并不是可以完全可以接受我们的消息并返回。现在需要实现这样一个功能,系统设定发往核心的最大session数,如果超过了这个限制则等待,直到核心给我们的系统返回处理情况,再继续发送。 系统和核心的交互式通过中间件Tuxedo来完成的。
首先想到的是使用队列,再起一个监控线程,每隔一段时间监控一下队列,如果队列里的任务项已经发送完成且返回,则把此任务项从队列里面删除,在把未发送的正在等待的任务项发送给核心。此方案实现较复杂,放弃了。
我用池实现了这个功能。具体的方案是这样的,在发送消息之前,我会从Pool中取出一个连接(GetAppContext),如果连接已经用完,则等待其它连接的释放;发送消息完且取得返回值之后,则释放这个链接,同时通知等待的线程可以获取连接(Release)。具体的代码我贴上来:














































































但是经过测试,发现效率较未使用池之前有所降低,之前发100笔任务只需要几秒钟,使用池之后大概需要15S,时间增加了好几倍,且随着任务量的增多比率呈上升的趋势。经过分析,发现是因为我用了ManualResetEvent 的原因,换成AutoResetEvent后,速度明显上升。原因在于当调用了ManualResetEvent.Set()后,所有等待的线程都被触发,消耗了大量的时间;而AutoResetEvent.Set()则只触一条等待的线程。关于两者的用法,我在"AutoResetEvent与ManualResetEvent区别 "中做了详细的解释。
在实际应用中,上面的代码还有一些缺陷:一是如果在排队的任务项超时如何处理,二是发往核心的任务项如果一直没有返回,则在排队的所有任务项一直处于等待状态,系统会造成死锁的状况。基于这两点考虑,我修改了一下程序,贴上代码:







































































































































































