交付报告未处理一段时间

交付报告未处理一段时间 搜索搜索

作者 信息
Nikos Mavrakis.
新成员
用户名:nmavra.

邮政编号:3
注册:05-2007
2009年6月11日星期四发布 - 08:53 AM:  

你好,
我们正在调查有关使用我们申请的两位提供商的交付报告的问题,似乎在大约2小时内报告未加工的报告存在问题。

似乎虽然从Nowsms收到的短信和交付报告,但在我们的系统中没有处理的所有报告左右。同时,正常消息,如正常处理。
我们的自定义应用程序不会显示任何错误。
您是否知道为什么会发生这种情况以及我们如何追踪它以找到错误的来源?
请查找附上问题日期的SMSIN日志文件,以及带有我们没有的消息的Excel文件'T有报告作为交付。
DES - Nowsms支持
董事会管理员
用户名:Desosms.

邮政编码:934
注册:08-2008
在2009年6月11日星期四发布 - 02:03 PM:  

嗨Nikos,

您是否正在运行IDSMS 2009发布候选版本?(我想你是因为它解决了另一个问题。)

2008.11.05和2009.04之间的所有版本都有一个错误,如果您有2路命令定义为不同的Web服务器,则有时ordsms将尝试将2路命令发送到错误的Web服务器。

更新到最新的2009年发布候选版本 http://www.zgbianpofanghuwang.com/download/nowsms2009rc.zip ....或作为快速修复,编辑smsgw.ini和[smsgw]标题添加2waykeekealive = no。

-
DES.
nowsms.Support
Nikos Mavrakis.
新成员
用户名:nmavra.

邮政数量:4
注册:05-2007
在2009年6月18日星期四发布 - 08:24 AM:  

你好des,
我们正在运行2008.11.27版,但我们不'T有不同的Web服务器,只有一个。所以我不'认为这是你提到的错误的相关问题。

我们编辑了SMSGW.INI并包括2长Keepealive = NO,但那就没有'似乎可以解决任何问题(所以我后几个小时就删除了它).

我们注意到的是报告aren'正在处理一段时间(可能是30分钟,1小时,2小时,它不具体)但之后一段时间就是某种方式"fixed" by itself.

所以经过一段时间不仅交付报告处理得很好,但我们也看到之前的报告也得到了处理好的。

处理传递报告的URL是同一目录中的页面(IIS application)处理正常SMS的页面,这始终有100%。
布莱斯诺伍德 - 诺斯姆斯支持
董事会管理员
用户名:布莱斯

邮政编码:7793
注册:10-2002
发表于2009年6月22日星期一 - 02:42 PM:  

嗨Nikos,

你可能不会遇到那些描述的同样的问题,但我'D仍然建议更新。

特别是,我'm对2008.11.27的更改说明,提到了一个性能增强,这可以防止大量的送货收据放慢其他收到的消息的处理。

如果内存正确为我服务,则此特定增强的第一次尝试减慢了送货收据处理。

-bn.
ashot shahbazian
新成员
用户名:Animatele.

邮政编号:10
注册:06-2004
在2009年6月27日星期六发布 - 11:44:  

检查丢失的DLR问题是否在午夜后修复了本身。如果它,原因可能是硬盘故障(或电源尖峰/故障如果启用磁盘写入缓存。)这可能会破坏用于DLR匹配的DLR匹配的数据中的数据库文件。一旦应用程序在午夜创建一个新的DB文件,问题消失了。其中一个指示也是一个相对较高的CPU负载,在某些核心比其他核心上稍高,与交通无关。

修复问题的唯一方法是删除相应的DB文件(易于找到它,因为它停止更新"last changed" time when broken,)删除上行链路并再次创建它。或者等到午夜。在任何一种情况下,先前发送但未传递消息的DLR都会丢失,它们在用户队列中累积。

这best way to prevent it is to use a good UPS.
Nikos Mavrakis.
新成员
用户名:nmavra.

邮政编码:5
注册:05-2007
2009年7月03日星期五发布 - 上午10:34:  

We've大约2周前更新了网关,但我们'仍然遇到这个。我们正在考虑自从我们的严重问题以来重建服务器,我们需要排除可能性。

报告停止被处理了很长时间,然后他们似乎在随机的时间后再次开始处理,然后将再次停止。


艾托谢谢你的建议,但我认为这与我们的问题无关。问题不会在午夜后修复,所以我怀疑它是一个腐败的DLR DB。

We'仍在寻找原因。
Nikos Mavrakis.
新成员
用户名:nmavra.

邮政数目:6
注册:05-2007
2009年7月03日星期五发布 - 10:48 AM:  

我忘了提到交付停留在SMSIN文件夹中作为xxxxxx.rec文件。网关在smsin.log文件中显示它们,将它们放在smsin文件夹中,但从那里他们没有得到处理......

有任何想法吗?
Nikos Mavrakis.
新成员
用户名:nmavra.

邮政编码:7
注册:05-2007
发表于2009年7月3日星期五 - 03:33 PM:  

更新:
在研究和试验之后,使用2waysmsthreadCount = ##在此处提出的设置:

http://blog.zgbianpofanghuwang.com/2008/10/2-way-sms-command-speed-and-performance.html

并设置2waysmsthreadcount = 100

我们从SMS-In文件夹中删除了所有待处理的.REC消息到一个新文件夹中,并开始一次移动.REC消息1000。

这gateway was then processing everything normally at very good speeds.

我们将继续监控这种情况并以更多信息回复您。
DES - Nowsms支持
董事会管理员
用户名:Desosms.

邮政编号:988
注册:08-2008
发表于2009年7月03日星期五 - 03:38 PM:  

嗨Nikos,

那是非常奇怪的。

有单独的程序线程处理*.REC文件使他们不会阻止*.IN files.

我能't看到任何会导致的场景*.REC处理来阻止。

这only thing I could think of would be that maybe it would help to allocate more threads to this processing.

编辑smsgw.ini,在[smsgw]标题下,添加2waysmsthreadcount = 5

这将分配更多的线程来处理这些消息。

-
DES.
nowsms.Support
ashot shahbazian
新成员
用户名:Animatele.

邮政编码:16
注册:06-2004
发表于2009年7月5日星期日 - 08:33 PM:  

我想我知道可能导致它:

检查followng:

- 是否包含SMS-IN目录中未处理的文件"收据edmessageid = xxxxxxx." in a separate line.

如果他们这样做,请检查:

- 是十进制或十六进制格式的xxxxxxx。在提交各个出站消息时尝试将它们与SMSC返回的消息ID-S匹配。文件中包含的那些是小数'd将您的SMSout日志中的ID-S匹配'd将文件从文件转换为hex。那'■为什么有些人被Nowsms跳过:它需要改进的十六进制转换器。

第二种可能性是文件不't contain the "ReceiptedMessageID"字段 - 这意味着SMSC上游'返回它们。再次检查,是否包含在送达的有效载荷中的消息ID(after "id:")十六进制或十进制。如果十进制,那'd是最难解决的,但如果十六进制和它'匹配您的日志中的那些's包含在MessageId字段I中'如果您发布了SMPPDebug日志的相关部分,则确认Bryce或Des将帮助您解决它(首先激活它,然后唐'忘记了停用它'耗资资源。)

希望这可以帮助。
Nikos Mavrakis.
新成员
用户名:nmavra.

邮政编码:8
注册:05-2007
发表于2009年7月6日星期一 - 10:55 AM:  

你好des,
在问题之前,我们的2waysmsthreadCount是= 6所以我们测试了一点,我们发现当它进入100时,问题消失了。

显然我们还没有't测试了所有可能的价值,但到目前为止似乎工作正常,并不是'真的危害表现。如果您认为100太大,请告知您是否太大并且应该改变。



ashot,sms-in目录中的.rec文件包含"收据edmessageid = xxxxxxx."在一个单独的行中。这是真的,因为现在rec文件被处理得很好,我没有'当我们出现问题时,我强烈地认为.rec文件的格式相同。

这是我们文件的示例。

[sms-in]
modemname = cimd - (SMSC IP)#13:9971
发件人=(msisdn number)
Phonenumber =.(short code number)
DATA = ID:4A47A77C子:001 DLVRD:000提交日期:0907061239完成日期:0907061239统计数据:extrestD错误:003
收据=是的
preceptmessageid = 4a47a77c

请注意,NowSM不会跳过处理它们,它只是停止处理它们并在将来随机的时间开始处理。这可以从后来或10小时的任何东西都可以从任何东西。

正如现在所处的那样,REC文件很快被处理,但我们将继续监控情况并了解它是如何发展的。

I'm涉及2waysmsthreadcount = 100,我们有..这可能是太多的,如果是的话,后果会是什么?
ashot shahbazian
新成员
用户名:Animatele.

邮政编码:17
注册:06-2004
发表于2009年7月06日星期一 - 03:02 PM:  

您是否检查了在这种情况下文件中的消息ID,4A47A77C,与相应出站消息中的SMSout日志中的行中的行匹配?如果它,那么我'm not sure what's the problem.

如果您经常停止/重新启动服务,则可以找到其他线索。有时它'S导致部分DLR不处理。如果出站消息已发送(a few days)在收到的DLR之前。此外,如果SMSC上游返回2个DLR,则具有相同ID-S的临时和最终版本。同样在以前版本的应用程序DLR"failed "状态会比那些更频繁地卡住"deliverd",但这可能是因为他们'重复比交付者更旧。

你的上行似乎是cimd。我们'没有CIMD的经验,也许'解决问题的根源。它'S不是广泛使用的协议。或者您与SMPP流量相同?
布莱斯诺伍德 - 诺斯姆斯支持
董事会管理员
用户名:布莱斯

邮政编码:7829
注册:10-2002
发表于2009年7月6日星期一 - 04:43 PM:  

We'仍然失去解释这一点。

我们确实有一个潜在的理论,我们看起来更密切关注......尝试一些测试,看看我们是否可以找到任何不寻常的行为。但到目前为止我们避风港'发现了任何问题。

但是,我确实希望为上述一些事情提供一些解释。

2waysmsthreadcount分配用于处理入站消息的程序线程。在当前版本中,实际上有两倍于分配的线程数,用于定期入站SMS和一个处理收据。那么你'vere每个人都有100个......都基本上等待其他程序线程在SMS-In目录中放置邮件。

100有点高,可能会降低其他区域的性能。

请注意,这些线程不仅仅是扫描SMS-In目录并为双向命令进行回调。他们的大部分延迟都会出现等待2路命令完成。

我想认为6会很高。

我也想提到这一点"ReceiptMessageID"输入,因为最近版本有一些变化。

*.REC文件是已成功解决的收据。除了将这些消息分配给双向命令之外,不需要进一步处理。他们以常规方式分派给双向命令*.IN messages do.

如果你有任何*.rct文件,这些可能是有问题的。这些是我们无法解决收据消息ID的内容。这些是更有可能被困的人。

这*.rct文件完全分开地处理*.REC and *。在那之后,他们不'T导致其他消息或收据延迟处理。

也许我们'LL在测试我们的一个长字理论时找到一些东西。

你可以在smsgw.ini中再次在[smsgw]下再次尝试2waykeekealive =没有。这是否有所作为。请注意,需要重新启动该服务以使设置生效。这是在这个帖子中早些时候的解决方案,但我'd想重新审视它。

-bn.
DES - Nowsms支持
董事会管理员
用户名:Desosms.

邮政编码:994
注册:08-2008
发布于2009年7月6日星期一 - 下午10:47:  

尼科斯,

所有的双向命令都基于HTTP吗?(We'一直在假设他们是......但如果有些人是当地的可执行文件可能有其他问题可以探索。)

-
DES.
nowsms.Support
Nikos Mavrakis.
新成员
用户名:nmavra.

邮政编号:9
注册:05-2007
2009年7月08日星期三发布 - 上午10:14:   

是的des,
我们有2个双向命令,它们是HTTP的同一服务器!

Bryce我做了你提出的并添加了2长的=否。

然而,注意,因为我们将2waysmsthreadcount号码上涨到100岁'因为我们不知道这个问题'知道是什么导致它在第一个地方我'm不是100%确定2waysmsthreadcount = 100是解决方案,自从我们可以't再现错误,我们只能等待,看看它是如何发展的。我们很少看到.rct文件,也许每10天左右。

Ashot谢谢您的参与和帮助,到目前为止,CIMD实际上没有广泛使用,但它也会发生SMPP。文件中的消息ID与日志文件中的消息ID匹配。

一位提供商根据案例发送EnRoute和交付收据。我们的申请无视途径报告,只有流程(updates our database)提供的报告。最后,即使在同一小时发送的短信也会发生问题,即我们发送了一个短信,但从未收到过任何收据。这不会发生一些随机的短信,而是整整一段时间。