SMS User Q appears to hang. | Search |
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through January 22, 2009 ⬆ |
◄ ► |
Author | Message | |||
Frank Grygus New member Username: Fgrygus Post Number: 5 Registered: 08-2007 |
Good day! I have recently come across a situation where I have incoming sms from a gsm modem(MultiTech) routing to a SMSUser account, that don't get delivered. The SMSUser is tied to an application that only supports text sms messages, which are delivered using only one Submit_SM/Deliver_SM packet. The problem as I see it, I received an advertisement WAP Push from the carrier which NowSMSC attempted to send to the application(using the SMSUser account). Because the application does not support WAP Push, it never sent the Deliver_SM response. More text sms messages were arriving, and put into the SMSUser Q. None of the new text sms messages were processed because the WAP Push message was "hanging" the queue. It appears the SMSUser Q is treated in a serial fashion, and as it's being processed each message has to be ack'd before it continues to the next. I was able to find the SMSUser directory, and view the items in the Q. After identifying the binary SMS in the Q, I deleted the files(while the NowSMSC service was disabled). Once the files were deleted, I started the NowSMSC service and noticed all the remaining sms text messages were delivered. Is there a way to instruct the NowSMSC to process all messages in SMSUser Q (in parallel), without waiting (or hanging) on one message that does not receive Deliver_SM response? Frank | |||
Frank Grygus New member Username: Fgrygus Post Number: 6 Registered: 08-2007 |
Additionally, Is it possible to have this condition reported by System (e-mail) Alerts. The NowSMSC GW emails me when the outbound Q reaches some threshold, but I do not get alerts when the SMSUser's Q reaches a higher value with respect to outbound Q thresholds. | |||
Des - NowSMS Support Board Administrator Username: Desosms Post Number: 198 Registered: 08-2008 |
Hi Frank, We have had some similar complaints in the past, but we had mostly written them off as flaky SMPP client software. If the client doesn't want to accept the message, it should still return a response. It can put an error code in the response if it wants. Or it could NACK the packet. To simply ignore the packet because it doesn't like the message type is bad practice. In either case, whenever we tested one of these scenarios ... response with error code ... NACK ... or no response ... we never saw a problem. If there was a response with an error code, NowSMS would not retry, assuming the client did not want the message. If there was a NACK response, NowSMS would move on to the next message, scheduling the problem message for a delayed retry. If there was no response, it would take 2 minutes to timeout, but NowSMS would then move on to the next message, scheduling the problem message for a delayed retry. However, I tried another test scenario today with a factor that we had overlooked. If the client ignores the message, but continues sending enquire_link at a regular interval, then the enquire_link was inadvertantly resetting the timeout that was waiting for a response, causing NowSMS to get stuck on the message. We are working on a fix to include in the next update. However, in the meantime, here's a simple solution. Edit SMSGW.INI, and under the [SMPP] header (if there is not a header of just [SMPP], add it), add CommandTimeout=25 This specifies the timeout that the SMPP server will wait for a command response. To avoid this problem, for now, this value needs to be smaller than the enquire_link timeout of any of your problem clients. The fix should be available soon. -- Des NowSMS Support | |||
Des - NowSMS Support Board Administrator Username: Desosms Post Number: 200 Registered: 08-2008 |
Hi Frank, We're going to go ahead and make this fix available in a testing release before a more general release. The particular fix to address this problem was not very complicated. However, we have also implemented a considerable amount of performance optimisations, and changes to the SMS routing logic, which effect core components of the NowSMS product. We've completed our internal testing of this update. However, because there were a large number of internal changes, optimisations and fixes, we are going to make this version available as a test release before general release. We're quite confident that this release is actually more stable and robust than previous versions. We know the performance and CPU overhead is much improved. We know that overall disk I/O has been reduced. And we know several rather significant bugs that have been fixed in this release. But, the problem with bugs is they are very much configuration dependent, and with such a large number of configuration options, we may have missed something that affects particular configurations, so we want to get some more feedback. This update can be downloaded at http://www.nowsms.com/download/nowsms200811.zip. -- Des NowSMS Support |