One of the users of my Management 'ERP' program has suddenly become unable to send emails via the program. As all the necessary definitions are contained within the database, it's not a problem of a wrong definition. An attempt to debug using a simple program that I wrote once that sends a standard email via Gmail and outputs all the status messages failed to send the email, but it's not clear (at least, to me) what the problem is. "Something to do with the user's computer" was my lame explanation; as it happens, the same non-result happens when I run that test program on my mobile computer, but this didn't lead to any further insights.
When discussing this problem with the OP yesterday, I had the idea that maybe instead of calling the 'send mail' function in the Management program, the email would be sent via a separate, auxiliary, program, in a similar fashion to the auxiliary program that I discussed1 a month ago.
So yesterday afternoon, I spent a few hours working on this. There were two major problems: the program should have to wait for the thread that sends the email to finish before closing itself, and that on my computer, the program is located at c:\program files\...... As a filename had to be passed to the auxiliary program, it made sense to write a console application (as is the previous auxiliary program) and get the filename via the use of the paramstr function. But the space in 'program files' causes paramstr to malfunction, producing two strings that have to be concatenated in order to get the filename.
Eventually this sort of worked but I wasn't very happy about it. Sometime during the night, I realised that I could use the 'OnTerminate'2 event to establish when the thread finished, solving the first problem. But at about 5 am, a new idea struck me: instead of executing an auxiliary program, have a constantly running program (a 'daemon') poll a given directory and send from there any email files that may have been stored there. Of course, having had this idea, I had to examine it from various angles and consider the polling code, and as a result I couldn't get back to sleep.
Later on, I realised that the idea of an auxiliary program was doomed from the start: although the program might be stored on the server, it would be executed from the user's computer and the original problem would still occur. Having a program that constantly runs on the server would solve this problem.
Only a minor change - and in fact, a simplification - was required in the management program; basically if the user is defined as 'aux mail' then the file holding the email is saved in one directory, otherwise the file is saved in a different directory and the email sending thread is executed.
In the daemon, I got around the 'waiting for the thread' problem by the program never closing. It has a timer that wakes up once every five minutes; first it checks to see if there are any files with the 'msx' extension in the mail directory - if there are, these files are deleted. Then the programs checks to see if there are any files with the 'msg' extension in the directory - these are the email files. If so, a loop runs over these files: the file is copied to a new file with the 'msx' extension, this filename is passed to the email thread and finally the msg file is deleted (so that it won't be found again).
After I finished working on this and checking that emails are indeed sent (and received), I had the idea that the management program should try to execute the mail program, and so the mail program had to have a semaphore that prevents it from being executed more than once. This is easy to add, as is the code to the management program to execute the mail program. Then I realised that the original problem is liable to occur again: the user runs the management program on her computer and so a new instance of the mail program will run on her computer - and probably won't be able to send email. So I removed the offending line from the management program; I'll have to remember to add the mail program to the startup list on the server.
We'll see how well this works during the coming week.
Internal links
[1] 1840
[2] 1838
| Title | Tags | ||
|---|---|---|---|
| 309 | The gravy boat | Cooking | |
| 310 | Copper socks 2 | Health, Copper | |
| 1093 | Two more people have passed away | Obituary |
No comments:
Post a Comment