错误消息 - 消息队列已满

错误消息 - 消息队列已满 搜索搜索

作者 信息
我要
在2003年10月3日星期五发布 - 06:42 PM:  

我现在有问题短信博彩5.0,我们遇到了此错误消息:
f7e0cad.req,127.0.0.1,+628561869573,重试待处理 - 错误:消息队列全 - SMPP - 202.155.46.14:30002
2003-10-03 23:24:04,3f7e0cad.req,127.0.0.1,+628561869573,重试待处理 - 错误:消息队列全 - SMPP - 202.155.46.14:30002
2003-10-03 23:24:20,3f7e0cad.req,127.0.0.1,+628561869573,重试待处理 - 错误:消息队列全 - SMPP - 202.155.46.14:30002
2003-10-03 23:24:36,3f7e0cad.req,127.0.0.1,+628561869573,重试待处理 - 错误:消息队列FUL

此消息阻止了所有的消息,我们已经使用了该号码的操作员检查+628561869573关闭手机和我们发送的所有短信在SMSC缓冲,缓冲的限制是100个短信,当101短信发送到这个号码时出现错误消息,请告诉我如何避免此事再次发生我可以手动删除"sending mechanism"哪个继续在消息队列满满时发送消息?
我尝试删除文件"Q"目录并失败,逆时针继续发送消息。
布莱斯诺伍德 - 诺斯姆斯支持
发表于2003年10月4日星期六 - 03:10 PM:  

我要,

这太有趣了。我猜不同的SMSCS使用此错误代码有点不同。几个月后,我们在SMSC的队列发生问题时遇到了此错误。 SMSC本身在一天的某些高峰期间不接受任何消息,偶尔会返回此错误。

我们调整了我们的意见,更好地应对这种情况。

在你描述的情况下,我相信我们应该以稍微不同的方式处理事情,重试之间的延迟更长。

但是这样的消息应该是't阻止传输其他消息。至少我可以'看看如何发生这种情况(除非SMSC发生错误时,否则SMSC打破了我们的链接).

I'LL运行一些测试,可能当发生此错误时逻辑无法正常运行,这确实是一个主要问题。(这么多,在这里放松一下。 )

您是否可以确认Q目录中的肯定是没有处理的其他消息?

至于手动删除文件,您应该能够执行此操作。您可能遇到的唯一问题是定时错误。您可能需要多次尝试删除,因为现在在尝试处理消息时,现在将锁定文件,但在处理尝试之间至少会有15秒的延迟。

-bn.
我要
在2003年10月5日星期日发布 - 03:12 AM:  

嗨布莱斯先生

对不起你的周末,我很抱歉 :-( ,我符合消息被阻止了,更像是2个目标号码在具有相同的问题时,我在日志记录上发出了一些示例:
req,127.0.0.1,+628562251453,OK - SMPP - 202.155.4,Text =""
2003-10-05 00:00:32,3f7fa55f.req,127.0.0.1,+628562107656,OK - SMPP - 202.155。,Text =" "
2003-10-05 00:00:32,3f7fa561.req,127.0.0.1,+628551025527,OK - SMPP - 202.155。,Text =" "
2003-10-05 00:00:33,3f7f9b73.req,127.0.0.1,+628563332613,重试待处理 - 错误:消息队列全 - SMPP - 202.155。
2003-10-05 00:00:48,3f7f9c72.req,127.0.0.1, +628563332613,重试待处理 - 错误:消息队列全 - SMPP - 202.155。
2003-10-05 00:01:03,3f7fa044.req,127.0.0.1,+628563332613,重试待处理 - 错误:消息队列全 - SMPP - 202.155。
2003-10-05 00:01:18,3f7fa06a.req,127.0.0.1,+628557800420,重试待处理 - 错误:消息队列全 - SMPP - 202.155。
2003-10-05 00:01:33,3f7fa143.req,127.0.0.1,+628563332613,重试待处理 - 错误:消息队列全 - SMPP - 202.155。
2003-10-05 00:01:48,3f7fa1d6.req,127.0.0.1,+628557800420,重试待处理 - 错误:消息队列全 - SMPP - 202.155。
2003-10-05 00:02:04,3f7f9b73.req,127.0.0.1,+628563332613,重试待处理 - 错误:消息队列全 - SMPP - 202.15
2003-10-05 00:02:19,3f7f9c72.req,127.0.0.1,+628563332613,重试待处理 - 错误:消息队列全 - SMPP - 202.1
2003-10-05 00:02:34,3f7fa044.req,127.0.0.1,+628563332613,重试待处理 - 错误:消息队列全 - SMPP - 202.1h
2003-10-05 00:02:49,3f7fa06a.req,127.0.0.1,+628557800420,重试待处理 - 错误:消息队列全 - SMPP - 202。
2003-10-05 00:03:04,3f7fa143.req,127.0.0.1,+628563332613,重试待处理 - 错误:消息队列全 - SMPP - 2
2003-10-05 00:03:19,3F7FA1D6.REQ,127.0.0.1,+628557800420,重试待处理 - 错误:消息队列全 - SMPP -
2003-10-05 00:03:34,3f7fa562.req,127.0.0.1,+628568559401,OK - SMPP - 202.155,Text =""
2003-10-05 00:03:34,3f7fa564.req,127.0.0.1,+628551025527,OK - SMPP - 202.155。,Text =""
2003-10-05 00:03:35,3f7f9b73.req,127.0.0.1,+628563332613,重试待处理 - 错误:消息队列全 - SMPP - 202.155
2003-10-05 00:03:50,3f7f9c72.req,127.0.0.1,+628563332613,重试待处理 - 错误:消息队列全 - SMPP - 202。
2003-10-05 00:04:05,3f7fa044.req,127.0.0.1,+628563332613,重试挂起 - 错误:消息队列全 - SMPP - 202.155如果此错误发生在2个或更多号码中,则无法发送所有邮件,他们继续尝试发送和下一个SMS为此2号码已队列下一行发送,这一直在发生并导致它背后的所有消息"marry go around"圈无法发送。
我与SMSC运算符讨论,我们可以在消息无法发送后重试1,2,3-ids的某些数字,他们猜测编译的参数,所以我无法手动设置。
请帮助我们Bryce先生的服务现在运作,如果有一些错误阻止发送,我们现在确实从Q目录中手动删除了这些消息。

最好的祝福
我要
布莱斯诺伍德 - 诺斯姆斯支持
在2003年10月7日星期二发布 - 04:11 PM:  

嗨iwan,

抱歉随访延迟。

我们在周末做了一些调查和测试。

我不't think that one (or more)这些消息将防止其他消息发送。但是,他们会在出境发送中产生相当大的速度。

每次遇到此特定SMPP错误条件时,我们都会在重试之前延迟15秒钟,以发送任何更多消息。(这是因为我们假设整个接收队列在SMSC上满是完整的...而不是特定电话号码的队列。)

但是,任何其他待处理的消息都应该被发送出去,看起来他们基于上面的日志文件的摘录。

基于此经验,我们对V5.0发布的最后一刻进行了一些更改,特别是专注于SMPP环境。

发生任何错误时,我们在重试发生错误的消息之前等待更长的时间段。其他消息将继续在连接上路由而没有任何延迟。

在这个特定的SMPP错误,接收队列已满,我们在我们最终放弃消息之前等待更长时间(与其他错误相反)。希望重试超时将在未来的版本中进行配置......在此版本中他们不是。

-bn.