| SMPP transaction lock due to message queue full |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ Archive through October 14, 2015 ⬆ |
◄ ► |
| Author | Message | |||
| marc bazimon New member Username: Marc_orange Post Number: 27 Registered: 01-2007 |
Hi Nowsms team , I have a small trouble. it seems that for a subscriber that has got his queue full , the mmsc try to send back the message again and again, by detecting a throttling error ( this behaviour is normal for COMVERSE smsc as it mapped the error ) . this conduct to have a large amount of retry fo this subscriber , approximatively two per seconds. the log file for SMSOUT is 6 timse bigger than a normal day. I did look for the information on the forum but i didn't find the solution. How to delete a message ,that is locked due to the subscriber absent or anything? i try to find it on the mmsc directory , by doing a search but with no success. thx by advance for advices , br Marc | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 5277 Registered: 08-2008 |
Hi Marc, It is unfortunate that the ESME_RTHROTTLED error is being used in this scenario. If ESME_RMSGQFUL (or any other error) were used, this could be handled better. There is some special handling for ESME_RMSGQFUL errors where the MMSC interprets the error as a subscriber off-line and begins holding retries of other messages to the same recipient until the first queued message to that recipient can be delivered. There is a configuration setting that allows any other error (except ESME_RTHROTTLED) to be remapped to this error. I am going to discuss this with engineering to see if remapping of ESME_RTHROTTLED to ESME_RMSGQFUL could be allowed, as I believe it would help your situation. For now, what I see is that if ESME_RTHROTTLED is encountered, the message is retried in rapid succession for 5 attempts. The message is then marked for a delayed retry, where the delay between retries gets longer with each error (except that there are always 5 retries). I assume you have SMPPThrottleErrorDelay=0 under the [SMSGW] header of SMSGW.INI, otherwise there are delays inserted which can really slow things down, as it is assumed that ESME_RTHROTTLED is an overall system issue, not one restricted to a single subscriber. -- Des NowSMS Support | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 5279 Registered: 08-2008 |
Hi Marc, We had some internal discussions about this today...and we are going to add a setting to remap ESME_RTHROTTLED to ESME_RMSGQFUL, as the way we handle ESME_RMSGQFUL by default is to assume the subscriber's receive queue is full. Wednesday of next week (May 6) is the target date for this update. In the mean time, make sure SMPPThrottleErrorDelay=0 is set under the [SMSGW] header of SMSGW.INI. Also, if there are any RetryDelay settings configured, they may need to be reevaluated. The raw queued messages are REQ files under the Q subdirectory. -- Des NowSMS Support | |||
| marc bazimon New member Username: Marc_orange Post Number: 28 Registered: 01-2007 |
Hi Des , Thx for your quick feedback as usual, regarding the mapping , maybe it is not required because several reason : - Comverse smsc do the mapping queue full into throttling error but other supplier don't do it , so the workaround could disturb other supplier as they are compliant with SMPP norm - remapping back throttling into message queue full could avoid loop but what will happen if they happen a throttling problem ( licence exceeded on the SMPP link netween smsc and smpp gateway). A last question , , in order to delete the looped message on the queue , can i erase all the file from Q\MMSCQ__ path? there's LCK and ERR file. thx in advance for your feedback Br Marc | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 5280 Registered: 08-2008 |
Hi Marc, The re-mapping of the error code would be configurable. We already have a setting to treat ESME_RMSGQFUL as a system throttling error. This would allow the reverse. The ESME_RMSGQFUL handling is nice because if a recipient is getting this error, it holds off retries for other messages pending for that subscriber. LCK and ERR files can be safely deleted. (If not, they will get cleaned up automatically after some time.) -- Des NowSMS Support | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 5286 Registered: 08-2008 |
Hi Marc, Here is a link for an update that has a setting to change the throttling behavior. http://www.nowsms.com/download/nowsms20150427.zip * SMPP: Previous versions assumed that the ESME_RTHROTTLED error code indicated a system level issue at the upstream SMSC, not an error specific to a message recipient. Some SMSCs return this error if there are too many pending messages for the message recipient. NowSMS expects the ESME_RMSGQFUL error code to be used for this scenario. An existing setting has been enhanced to allow ESME_RTHROTTLED to be remapped to ESME_RMSGQFUL. To perform this remapping, edit SMSGW.INI, and under the [SMSGW] header (or [SMPP - server:port] header), add SMPPQFullErrorCodes=58 (0x58 is the numerical value for ESME_RTHROTTLED). -- Des NowSMS Support | |||
| marc bazimon New member Username: Marc_orange Post Number: 29 Registered: 01-2007 |
Hi Thx a lot for your quick answer i will give the updated NOW MMSC binary to O&M team and try it, We will discuss the fact that if a license exceed proceed on the MMSC-SMSC link, the error will be also mapped so it could be another trouble. Br Marc | |||
