Local Personal SMTP Server

[stanlyn]

Hi,

I'm looking for a small and local (on same machine) SMTP service or app that always runs outside of VFP on the same machine so that when I send an outgoing email from my VFP app, this service or app intercepts and contacts the actual smtp server for delivery. My app remains completely responsive at all times even when there are network, smtp or other external issues. I'm using it to send error emails with screenshots back to us.

Currently I send it to the smtp server directly from VFP and because now I'm including screenshots in the emails, the app is tied up for way too long, like 30-40 seconds for a 3.5mb screenshot file. I want the app to only prepare the email and hand it off to this ??? (that is outside my app) and continue doing what the app does with zero user delays...

I briefly look at the "VFP Parallel" processing articles a while back and wondering if that is overkill for this task?

I also looked at SmtpQ product from ChilKat which does exactly what I want, except it is only available in 64b...

Something simple is preferred?

Any ideas?
Stanley

 

[stanlyn]

Hi strongm,

>> what happens if you launch the mailsender from
Start>Run>d:\cpos\server\mailsender.exe

It runs immediately. The exe always runs immediately no matter how it is called. The issue is the run /n ties up the main program.

Thanks, Stanley

 

[stanlyn]

Olaf,

>> Also with SCREEN=OFF config.fpw included.
I DO NOT have either of these,


In your test, instead of a messagebox that pauses the program, put it into some sort of a busy loop doing something that last for 30-60 seconds and see if you get any tie ups. The messagebox kind of ends the events loop effectively putting vfp into an idle state.

Thanks, Stanley

 

[Olaf Doschke]

>I'm using it to send error messages and screenshots back to me from the customers site.
>The need to preserve the emails is in another app I've created where clients are charged money for the emails, hence the need to make sure they are delivered.

So these are two uses for the mailsender.exe, right?

If you'd only send mails in case of errors just having been handled, the main app might be in any non stable state, though stable enough to log errors. I think most of mainly log errors in the general handler and quit the app, sending errors could be done at next startup, especially in a multi user environment, that happens sooner or later anyway, and you collect errors from all clients.

In regard of the other use I assume a more reliable state of the main executable running the mailsender.exe

Anyway, have you tried using the process monitor tool?

You could simply create a new exe that only starts the mailsender.exe and see if that reproduces the problem. Then set up a filter in procmon.exe to log events of yourtest.exe and see what may tie up this exe.

Bye, Olaf.

 

[stanlyn]

Olaf,

>> So these are two uses for the mailsender.exe, right?
1. error messages.
Yes this is one usage.

2. >> billable emails
Yes I have several apps that can email pages from land records books and some can be 100 pages long which would creat a large .eml file. For 10+ years now I've used blat and emailed a single page per email and because the page was 1-bit tif, that went thru just fine...

EXCEPT for:
1. ISP's that blocks port 25. I'm attempting to build the new system that handles SSL and TLS for those ISPs that blocks port 25,

2. Include the ability to package all files needed (pages 200-300) and mail them in one email to the kiosk user's on-file email address and allow them to continue their research, and possible email another batch (pay per),

3. Add in sms messaging is also being included as it is very similar to smtp


Now, that I'm rewriting this its time to solve the issues and limitations I had with the old blat system.


My testing is done with an "on error do errormessage" handler where it collects the info for the smtp stuff and after packaging it, it hands it over to MailSender and the main program continues.

All message data and screenshots are saved in the table "message" that resides on the server component. This way the client can mail it from the client without all pathing issues of OS stored files. (note all my dev and testing is actually done at the server which does NOT introduce any client/server issues with this current "run /n" issue)

My testing was done with an intention error I put into the menu, something like a=2+z and z was not defined. Just an easy way to involke an error.


?? have you tried using the process monitor tool?
Yes a little, nothing big like we need here...

Thanks,
Stanley

 

[Olaf Doschke]

>My testing is done with an "on error do errormessage" handler where it collects the info for the smtp stuff and after packaging it, it hands it over to MailSender
Is it really important you get the new error mailed right away?
When the error is in the message table, any time later mailsender.exe can pick it up.

>...and the main program continues.
I'd say most of us don't continue execution after any error was logged by the general error handling. As this handling is for unspecific unexpected errors continuing the program code can harm, eg working on the wrong workarea after a SELECT xyz failed, because xyz is missing. In the worst case you can shred your data. It also depends on a defensive coding, eg ZAP only with IN alias clause, otherwise a previous failed SELECT that triggers error handling and means you return to the next line where a single ZAP may delete anything you didn't want to. Some of the more harmful things like ZAP need exclusive access, so normally the harm just is a follow up error, but I'd not bet at this.

In your test case of course the app is not in any such harmful state nor is it having dangling references or releasing a larger OLE object or anything else, that would explain a tie up, so it remains a mystery and since you can't go on a finer grnular level on a single command like RUN your only hope is Process Monior finds out what happens during this single command in detail, and there is a lot happening, which can be compared to a case not tieing up.

Not related to the RUN /N problem I'd recommend you only do RETRY or RETURN from the error handler in cases you're absolutely sure this could not harm. A way to cancel all current activities is the quite unknown RETURN TO MASTER, returning to the highest level calling program. But that still in general leaves current erronous form/class/object open in its state. So I'd rather quit and put the call to mailsender.exe at the startup of my application, to send eventually new errors, not only of this installation, if the message table is shared in a network share.

Bye, Olaf.

 

[stanlyn]

Hi Olaf,

>> Is it really important you get the new error mailed right away?
Yes and no... No if it is for error messages, and Yes if for the paid emals from customers. I am rewriting the routine to mainly solve the customer paid system and use it for sending errors which could be done later. I want only one system to maintain, so I need to build one that servers all.


>> I'd say most of us don't continue execution after any error was logged
Depends on the error. I test for the error number in the handler and many errors that is expected (out of paper, etc) is trapped and many do lead to a shutdown while others are not. This approach has been working for years.


>> returning to the highest level calling program. But that still in general leaves current erronous form/class/object open in its state.
Yes, you are correct and that is why I said "depends on the error" above.


>> put the call to mailsender.exe at the startup of my application
Good idea, and will probably use this for the error sending...

Thanks,
Stanley

 

[Olaf Doschke]

>In your test, instead of a messagebox that pauses the program, put it into some sort of a busy loop doing something that last for 30-60 seconds and see if you get any tie ups
I already did, I put a DO WHILE .T. ENDDO loop in the called exe. The messagebox isn't there it's at the caller side right after RUN /N to show it continues and visually shows something, the same happens, if I only do a ? "Hello" _screen output.

The other options I mentioned about SCREEN=OFF were about strongms assumtion it could have to do with the new process becoming visible. Neither becoming visible, nor having a HWND, nor going into an idle state is needed for RUN /N to come back from starting the other process and let the caller continue with its code.

At this point it has become quite uninteresting, why RUN /N may tie up, I'm very confident it doesn't impact my applications using RUN /N for decades and still under Win8.

Bye, Olaf.

 

[strongm]

>strongms assumtion it could have to do with the new process becoming visible

That was not my assumption.

> put a DO WHILE .T. ENDDO
Just out of interest, perhaps you could try a Sleep 30000 call instead

 

[Olaf Doschke]

OK, sorry for saying so, but you said

a test worth doing would be for Stanlyn to make the mailsender.exe display a top-level form at startup

Maybe you thought of another effect than this top level form becoming visible, but it is one detail I also tested with both SCREEN=OFF and not, without using an additional top level form, _SCREEN already is one.

Bye, Olaf.

 

[strongm]

>Maybe you thought of another effect than this top level form becoming visible

Yes, it was a quick way of testing whether there was an issue with the way FoxPro may or may not use WaitForInputIdle

 

[Olaf Doschke]

Well, I didn't investigated on that, but wouldn't WaitForInputIdle nee some control expecting input? I'd say even an empty form, anything that has a hwnd can become the addresse of eg WM_KEYDOWN events, so it'll get to the InputIdle state eventually. It doesn't matter, as RUN /N even isn't tied to the WHILE .T. loop, that version of the called exe has no Idle state ever and still doesn't tie up RUN /N.

Bye, Olaf.