Users and queue management and other problems

Users and queue management and other problems SearchSearch
Author Message
Dziugas Baltrunas
New member
Username: Menulis

Post Number: 1
Registered: 02-2006
Posted on Wednesday, February 08, 2006 - 09:01 am:   

Hi,

we're using NowSMS v5.51 (b20050809) as a MMSC. I will try to list some major problems that we're dealing with.

1. Occasionally (once a three days or so) mmsc-*.log stars blaming about "User Not Defined" error for MM1 users trying to send a MM, hence users get a sending failure. Restarting a MMSC service makes the think work ok again, so this is definitely a NowSMS problem. We're using automatic user provisioning (MSISDNHeaderAutoProvision=Yes), so currently there is quite a big amount of users (MSISDNs). Records in the log file look like this:

2006-02-08 09:17:36,MMSIN,192.168.150.2,,,User Not Defined,FAILED

After an ordinary "User Not Defined" problem in userdef.log I noticed, that just before it there was the same user added twice:

TimeStamp=2006/02/02 22:48:05
Action=Add
PhoneNumber=+370xxxxxxxx
--------------------
TimeStamp=2006/02/02 22:48:05
Action=Add
PhoneNumber=+370xxxxxxxx

I see, that in userdef.log there are several such situations (adding the same user) and not each time blaming about "User Not Defined" starts. However, I thought that in some cases there might race condition occurs which locks MMSCUsers.DT[I,A] files, but it's only a guess. I also saw somehow similar problem in forums (http://support.nowsms.com/discus/messages/485/7937.html), but our case is different as there are >2 users.

Unfortunately I don't have mmscdebug.log snippet for the situation described. We tried to enable debug log, but after few hours NowSMS started to eat most of the CPU so we had to disable it.

2. NowSMS/MMSCUSERS folder stores as many files as a number of users, so currently there are thousands of them and I guess this might slow down things as well as relate to described #1 problem. As I understand each file in the folder holds a statistical information for the particular user and since we don't use them, is it possible to disable statistics collection?

3. NowSMS/Q folder currently holds about 8k SAR-recipient.err files, where "recipient" is often malformed like ".", "kgnj", etc., but there is a part with normal MSISDNs as the recipients. Is it safe to delete these files and why NowSMS does not clean the files itself (oldest file is more that one year old)?

NowSMS/MMSIN/DECODE folder also holds quite a lot (currently 2.5k) folders which one or more files inside which I guess is for incoming MMs. Some folders' modification date is again more than a year old and since MM has expire time, why isn't the files cleaned up automatically?

Generalized summary of the #3 issue is the questions about the strategy to clean up various queue directories.

Thanks in advance.

Regards,
Dziugas Baltrunas
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 5539
Registered: 10-2002
Posted on Tuesday, February 14, 2006 - 08:58 am:   

Hi Dziguas,

1.) It sounds like the MMSCUSERS.DTI/A files have somehow become corrupted.

The quickest solution at this point might be to delete these files and let the users be re-added.

The upcoming NowSMS 2006 release changes the format of these files (and converts them to the new format when it is first run), and it has a rebuild utility in the unlikely event that the files become corrupt. Unfotunately, there is not a rebuild utility for the current release. I'm going to check with engineering to see if they can produce one ... but if it is not a problem for your installation, which I suspect it might not be, then the quickest solution would be to delete these files and let the users be re-added.

2.) All of this has been changed in the upcoming NowSMS 2006 release. The MMSCUSERS directory is restructured so that it uses multiple subdirectories (preventing the problem of having so many directory entries). And there is also an MMSC.INI file option to disable these files completely.

For now, if you are not using those statistics, there is no harm in deleting those files.

3.) Again, we've made changes in NowSMS 2006 to address the issue with the NowSMS\Q directory. For current versions, there is no harm (only benefit) in deleting these files manually. Most of these errors occur in the first place when users submit MMS messages addressed to malformed recipients, and NowSMS 2006 also makes changes to reject these messages at message submit time, instead of allowing the messages to get to this stage.

Regarding the NowSMS/MMSIN/Decode directory, I would like more information. What is the most recent file that you have in this directory? And what is the version of NowSMS that you are running? It might be helpful if you forwarded a ZIP of the files here to my attention for further inspection, as it is not normal for leftover files to be in this directory. (Although I do know that there have been bugs in some past versions where some files were left behind.) This is a temporary decoding directory for messages received via SMTP and/or MM4. If you could ZIP some of those files and e-mail them to nowsms@now.co.uk with a subject line of "Attention: Bryce" ... and reference in the message that these are left-behind messages in your MMSIN\DECODE directory, then this would be helpful.


-bn
Dziugas Baltrunas
New member
Username: Menulis

Post Number: 2
Registered: 02-2006
Posted on Monday, February 20, 2006 - 11:22 am:   

Hi,

1) I might not have correctly described the problem, but I think that deleting MMSCUSERS.DTI/A manually and let NowSMS recreate them would only be a temporary solution, since it would fulfill again after some amount of time and same problems could appear.

As I wrote, the behaviour dissapears after restarting the MMSC service, so I think that generally these files are not corrupted, but get this state occasionally (once a few days or so).

Some more details how to delete these files in safe manner (i.e. do we need to stop MMSC service before deleting) would also be appreciated.

2), 3) Again, is it safe to delete them while running the MMSC service?


NowSMS/MMSIN/Decode:

Currently there are 5272 entries (both files and directories) in NowSMS/MMSIN/Decode directory. The newest entry (directory or .HDR file) is couple of hours old and the oldest one is more than a year old. We're using NowSMS v5.51 (b20050809).

Thanks,
Dziugas
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 5576
Registered: 10-2002
Posted on Friday, March 03, 2006 - 08:18 pm:   

Dziugas,

Apologies for the delay in response again. Now that we've finally completed the NowSMS 2006 version release, response timings here on the discussion board should return to normal.

Regarding #2 & #3 ... absolutely no problem deleting these files while the server is running.

Regarding NowSMS/MMSIN/Decode, considering that you're running v5.51, I'd definitely suggest an update. You don't have to jump directly to NowSMS 2006 ... there is a patch update for v5.51 which is v5.51k. And I think you should update to it. It can be downloaded from http://www.nowsms.com/download/latestpatch.zip.

There have been issues that we have found with files in that directory not being properly deleted (mostly to do with multipart/alternative messsages if I recall correctly, where the text of a message is part HTML and part text). So I would expect v5.51k to resolve this. It is not a problem to manually delete those files (even if the server is running).

I'm more concerned about item #1. While I haven't seen any problems with these files becoming corrupted, I could see how it could be possible to occur if there was a system crash. But what I can't see is a situation where restarting the server would resolve the problem.

Maybe I can ask you to e-mail me the mmscusers.dti/a files? I would like to run some tests on them to see if I can identify a problem. If you can ZIP them and e-mail them to nowsms@now.co.uk with a subject line of "Attention: Bryce", then I would like to see them. If the files are too large, let me know via e-mail, and I can setup a temporary FTP server.

-bn