Hello… we’re getting an anomalous timeout with Teradata and TDP. We have updated/tested timeouts in the .NET Data Provider config xml and TDP with greater values and zero. There still seems to be a 30 second timeout somewhere we cannot account for that gets triggered when the server gets a little busy. I have spoken with one of the DBAs and they are not aware of a 30 second timeout on their side. Below is an example of the error received.
Run_SQL - [.NET Data Provider for Teradata] [100038] Command did not complete within the time specified (timeout).
[Teradata Database] [3110] The transaction was aborted by the user.
[Socket Transport] [115003] The receive operation timed out.
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
Teradata 15.10.7.14
TDP 4.3.0.718 64 bit
Any ideas as to where there might be another timeout setting that we are missing? Is there more information I might be able to provide to narrow this down? DBA and I ran a stack trace and while he was able to identify the timeouts there was no pattern. I can’t guarantee I’ll capture them either as they seem to be minutely random.
Dave
1 Like
Hi Dave,
There could be different reasons for such situation.
By default Toad Data Point sets 180 seconds for foreground and 0 (infinitive) for background execution. You could check the values on Tools|Options|Database|Timeouts form.
Usually DBA sets timeout for idle sessions on server side. But your DBA eliminated it.
Also it could be related to TCP ‘KeepAlive’ setting. You could look at https://support.esri.com/en/technical-article/000006285 to see how to change it.
Regards
Aleksey
1 Like
Thanks so much Aleksey… still trying to track down a solution to this. I changed the TCP Keep Alive to 300 sec and we’ll see if the makes any kind of a difference. The default value was 60 seconds which doesn’t fit the pattern of the 30 sec timeout. I’m also asking on the Teradata forums where some others have suggested that it is a server-side issue (which I suspect). A DBA colleague is looking into this.
The issue is always when there is a higher amount of connections to database of course. Saturday mornings this isn’t an issue. There seems to be a misspelled CommandTimout setting in the .NET Data Provider XML… CommandTiimeout. I’m trying to find out if that is accurate or not. I have tried both spellings and result were indeterminate.
Dave