App hangs when smtp send fails due to unavailable mailserver

[Kevin_R]

We had our deposition automation software (written in Labview 7.1)  stall this weekend when network maintenance made the smtp server unavailable.

The software can send small status messages to a list of users (using the Send Small Message vi) when programmed to do so by the control script, or to notify the operators of an error condition.

I had thought that if the mailserver was unavailable, the programmed messages would just fail and the application would just continue merrily on its way, but apparently that wasn't the case.

Is there a way to test for this condition so it can be handled appropriately rather than stalling the application?

[Kevin_R]

An update -- it turns out the hangs were because the subvi to handle sending scripted messages returns an error which then triggers our process error handler, which in turn calls for help from the operator via email and then waits for operator intervention.

So Labview itself did not hang or stall; the software did what it was supposed to do.

Unfortunately, the error code being returned is 1, which is far too generic to parse out to "mailserver unavailable" and hence add to the list of "ok to ignore" conditions for the process error handler.

[Kevin_R]

It turns out the error handling in the SMTP Email Send Message (Small).vi is something less than optimal, to wit:

Inside the vi, if the TCP Open Connection fails due to a malformed server address (or, say, a nonexistent mailserver), it returns an error code 54. The send message vi, however, in the course of handling that chains it through a TCP Write function that passes out an error code of 1 because the TCP Open also returns a bad handle for further TCP/IP operations, which, of course, is passed to the TCP Write along with the error cluster... and the TCP Write returns an error 1 for the bad handle instead of the original error 54

I think this is a bug... The error code passed into the TCP Write Error In connector should have higher priority than the bad handle.

I have rewritten and saved in one of my libraries the a copy of the VI in which, if TCP Open fails, a case structure prevents any further TCPIP transactions from being attempted and returns the initial Error Code (54 or whatever).



With this modification, I can now capture the error code 54 in my calling code and treat it as a minor error/warning rather than a process error that triggers the operator intervention subvi.

[Megan B.]

Hi Kevin,

Thank you very much for letting us know about this.  I will bring it to the attention of some of our developers so they they can investigate further.

Megan B.

National Instruments.