I have noticed a LOT of messages almost daily now for SMTP email “socket” errors coming back from Toad Data Point. The end of my automations are supposed to send an SMTP mail message saying that the process is complete. Just one out of a lot of automation processes is coming back with this error quite frequently now. It emails me and says that the automation failed on the SMTP email because “a connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond”
The interesting thing is that the error message itself set up in the settings uses the same SMTP settings, so it emails this error just fine to me :).
It’s not a huge concern and there very well may be some connection or timeout issues with our SMTP server, so what I’m wondering is if there is a way to increase the “timeout” somehow so that it has longer to try to send the email? Is there anything that can be done as far as settings to help resolve this here? If not, is there any automation “if” things that I can put together to do a retry?
There are no options for SMTP. If you turn on verbose logging the SMTP component will provide a very detailed log of what it is doing. Perhaps this log will provide some more info. Beyond that you might need to get some help from your IT department.
Debbie, I understand there are no options for the users for SMTP and I’m betting I’m going to have extreme difficulties getting our IT folks to isolate and make changes to SMTP settings on our side. Therefore, I’m just wondering if there’s set timeouts in the TDP software itself and if maybe the “software-wide” timeout settings may be a bit low for timeout and could be extended in any newer version? I wonder if any other users have experienced anything similar and just thinking if there’s any ways that the issue could be worked around. Lastly, do you think there’s any type of looping or if properties that may be set to “retry” when experiencing that timeout issue? Just thinking of any ideas possible, because its definitely something that’s probably going to be difficult to change company wide on my end and most likely TDP wide on yours
I looked briefly in the help file for the 3rd party control we are using for SMTP email. I don’t see a configuration property for timeout. Can we see if this is still persisting at the first of the year and if so I can open a support case with them and dig deeper on this?
We connect and routinely connect to Netezza. I believe the mismatch would be between your driver and the version of Netezza. What is the version of each?
That I have no clue :). I do have some IT guys on our end trying to research the SMTP timeout issue as well, so maybe they will have a solution in place before January. I’ll update the ticket if there’s been any changes on my end and we’re still seeing the same issue.
Debbie, I want to apologize for not getting back to you sooner on this. I’m still having issues even on 3.7 regarding SMTP timeout. Our IT folks are not stating that there’s an issue on our end directly. I notice in our previous conversations you mentioned the version of Netezza. Is that something that is installed along with TDP for use with SMTP? Do you know where I find the version information for you to have? I’d like to see if possible if we could continue to still research the SMTP timeout errors I’m getting, especially again since it times out on a lot of the emails, but I get no timeout issues on the actual error email using the same SMTP. Please let me know what I can provide for you and I’d be happy to gather whatever needed for a possible ticket with Neteeza.
Let’s start from scratch on this one. Can you send me a complete log file and automation script of this error. make sure Verbose logging is turned on from the settings activity.
No problem. Starting over is probably great. I will turn verbose logging on all my email activities and next time it comes up, send your way. Thanks a bunch for helping me look back into this.
Good morning Debbie. I have an example of this SMTP issue we are discussing and have the verbose log and automation ready to send. It has some personal IP and email address info. Is there any way I can email directly to you? If so, could you please let me know how I can get this information to you directly, instead of posting on the public discussion? Thanks!
Did you ever resolve the issue on this thread? I am having the same issue tryinhg to email a report via an automated process TDP 4.0. Every thing runs perfectly until it gets to the email part of it and this comes up …
Socket connection has timed out. InnerException message follows: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond xxx.21.129.41:25
There were quite many changes in how the SMTP settings are handled in the latest TDP version. You might want to try the latest free beta version. Additionally you will have the option to specify whether to use the SSL or TLS secure authentication.
Or maybe first you might try to google that specific error message - usually it’s a response from the SMTP server itself or, like in your case, a timeout - maybe port blocked within your secured network, or invalid login details etc.
I am using Toad 4.3 and I encounter the same problem. In an automation whit a loop function emails with attachments are send out of a (sub) query produced results. This automation generates 6 files and should generate 6 emails but only the first 3 emails/files are send but the last 3 aren’t and generate above mentioned error message. The tail-end of the automation, after the loop, is a second email action that should send me the, verbose, log file and that also fails.
Sounds like your SMTP is slow and we are not waiting for confirmation of being sent. Keep extending the pause to see if you can find the right calibration. I have not seen this before.
In another application unrelated to TOAD I experienced a similar problem and it turned out to be the SMTP server choking emails to avoid being identified as a spam sender. Maybe something to consider?
