NowSMS Gateway won't open after Server Reboot

NowSMS Gateway won't open after Server Reboot SearchSearch
Author Message
Jeremy Baxendell
New member
Username: Jbaxendell

Post Number: 1
Registered: 12-2012
Posted on Friday, December 07, 2012 - 05:40 pm:   

I've restarted the server where the NowSMS client runs from, but Now the Gateway won't open, and the service, while it says it's running, isn't processing MMS messages. Any idea what's wrong?
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4230
Registered: 08-2008
Posted on Friday, December 07, 2012 - 05:58 pm:   

The configuration program won't open? What happens when you try?

What if you run SMSGW.EXE directly?

Even if it is nothing is displayed, does the task manager show SMSGW.EXE running?

I have no experience with any problems of this nature. It sounds like a corrupt DLL ... but I can't imagine how this would happen.

I'd suggest trying a reinstall.

If that doesn't resolve it, perhaps a configuration file is corrupt. I've never seen a corrupt configuration file cause a problem like this, but I can't imagine what else would keep the configuration program from running. Try deleting SMSGW.INI and MMSC.INI to see if the problem is related to these configuration files. (Save a copy first, so you can restore the settings later.)

--
Des
NowSMS Support
Jeremy Baxendell
New member
Username: Jbaxendell

Post Number: 2
Registered: 12-2012
Posted on Friday, December 07, 2012 - 06:10 pm:   

The SMSGW.EXE process seems to be running in Task Manager under Processes.

Additonal information. We changed intercarrier providers, and something was causing a lot of traffic to be looped through our system, creating a lot of files to be created in the MMSOUT folders, and increasing the size of the files in the records folder.

Whatever mechanism gives the count of MMS/SMS processed probably uses these files to get those numbers. Could the number and/or size of these files cause the gateway UI to be delayed for an extended period of time?
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4231
Registered: 08-2008
Posted on Friday, December 07, 2012 - 06:37 pm:   

Yes ... that is a good point, the UI might be scanning files at startup.

The service process could be doing this as well.

I do recall a similar incident now, there was a large collection of inbound messages queued for 2-way command processing, but no commands were configured. In this case, the SMS-IN directory was overloaded and scanning it took a very long time.

How is your system typically used?

I will do some investigation to report what other directories might be scanned at startup.

--
Des
NowSMS Support
Jeremy Baxendell
New member
Username: Jbaxendell

Post Number: 3
Registered: 12-2012
Posted on Friday, December 07, 2012 - 06:44 pm:   

Heh, 15 seconds before I got this response, the the NowSMS Gateway started up. About an hour after I attempted to start it. But the Service appears to be started, but I'm not seeing anything being processed.

We're a small regional carrier using the MMSC for our subscribers to send MMS messages to our wireless subscribers and other carriers' wireless subscribers.

I'd love to get a list of what directories are scanned at start-up.
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4232
Registered: 08-2008
Posted on Friday, December 07, 2012 - 06:46 pm:   

Is this an older install? What version?

NowSMS does scan the Q directory (outbound SMS) at startup. (Newer versions do this in the background, but older versions did scan at startup.)

I recall one issue with a large number of *.ERR files under the Q directory structure. This is SMS messages rejected by the upstream provider. By default they are retained for 72 hours (to allow them to be easily reposted in the event of a temporary upstream server problem). However, I believe in some older versions these files were never cleaned up.

If this is an MMSC, the MMSCACK and MMSCOUT directories can be a source of issues in the event of misconfiguration. However, these directories would not be scanned by the configuration program, and should not delay it from starting up.
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4233
Registered: 08-2008
Posted on Friday, December 07, 2012 - 07:05 pm:   

These directories are not all necessarily scanned at startup, but I would advise checking them for a large file build up:

SMS-IN - Messages queued for 2-way command processing (if you are not expecting to receive SMS, this can be a problem area)

Q - Outbound SMS

VASPQ - Outbound MMS destined for another MMS server (MM4, MM7)

MMSCACK - MM4 acknowledgements destined for an MM4 carrier partner

MMSCOUT - MMS to e-mail (in older versions, MM4 acks are also queued here)

Although the config program should not be scanning it, based on your setup, I suspect you are having a problem with a misconfigured MM4 connection and a severe MM4 backlog. (I am wondering if maybe the service could be scanning these directories and locking some control files that are delaying the config program load.)

If there are a large number of files in MMSCACK or MMSCOUT, stop the service and move the content of these directories before restarting. Content can be re-introduced if necessary.

A build-up of MM4 acks can occur if the "MMSC VASP" inbound connection does not have a valid "MM4 Ack Routing" property defined. In this instance, if acks are requested by the other side of the connection, the MMSC generates them but gets confused about processing them.

If this is happening, correct the configuration and manually delete RFC and INI files from MMSCOUT or MMSCACK directory.

If there is not a build-up of files in one of these 4 directories, then there is another possibility. It has been several years since we have seen a problem, but a corrupt message in the MMSCIN directory (.RFC file extension, inbound MM4) has triggered issues in older product versions.

Hopefully the solution to your problem is in one of these areas. I suspect it is an MM4 ack buildup from a missing ack route. (We would be better off not generating the acks if a route is not configured, because of the problem it can lead to.)

--
Des
NowSMS Support
Jeremy Baxendell
New member
Username: Jbaxendell

Post Number: 4
Registered: 12-2012
Posted on Friday, December 07, 2012 - 07:20 pm:   

Our version is 2012.06.28.

Looks like the MMSCOUT directory is full of *.RCF files, Over 600,000 of them. The Q and MMSCACK folders are practically empty, and the VASPQ is at a managable size.

What exactly ARE these .RFC files?
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4236
Registered: 08-2008
Posted on Friday, December 07, 2012 - 07:31 pm:   

Your version is current.

They are undeliverable MM4 acknowledgments, probably mixed with some MMS to e-mail that has not been processed.

Current behaviour is to route MM4 acks via the MMSCACK directory if an "MM4 Ack Route" is configured. However, if no route is configured, they end up in MMSCOUT which is a generic SMTP out queue. (As I indicated earlier, my opinion is that if no "MM4 Ack Route" is configured, they should not be generated. I will revisit this issue with the rest of our team.)

Check your "MMSC VASP" accounts and make sure that for any MM4 connections, an "MM4 Ack Route" is configured that links back to the outbound MMSC route for this MM4 connection.

This will stop these files from building up in the future. Old MM4 acks (most of your RFC files) are of no use and can be deleted.

What you will see, if you look at these RFC files as text files is that they are SMTP format e-mail messages. Most of the files will be MM4 acks, but some will be old user MMS to e-mail that did not get processed. It is probably best to just delete it all, then monitor after configuration change to make sure there is no further build-up.

--
Des
NowSMS Support
Jeremy Baxendell
New member
Username: Jbaxendell

Post Number: 5
Registered: 12-2012
Posted on Friday, December 07, 2012 - 07:44 pm:   

Interesting. Thanks for all your help, Des!