More on .NET Timeout Problems with SDK 2.81

I'm also having timeout problems using the IBM.Data.Informix classes. The release notes that came with the SDK say it is 2.81 UC3. I think there's a deeper problem - I think these are not 'real' timeouts. The timeout is happening in a simple query that takes 3 seconds to run from isql during the day (when the server is busy) but causes a timeout error when run in a .NET Windows Service during the evening (when the server is quiet). We've tried it at different times of the night so we're pretty sure it's not a genuine timeout problem. It does not clash with an archive or anything similar. We think there's a bug in the IBM.Data.Informix classes. The database is IDS 7.2. Interestingly it seems there is a ConnectionTimout property which you can get from the IFXConnection object, for example Dim Conn As New IBM.Data.Informix.IfxConnection("your connect string") Conn.Open() Debug.WriteLine("Timeout : " & Conn.ConnectionTimeout) With a normal connection string this displays the value 15. Now if you run a command like the following Dim strsql As String = _ "set lock mode to wait; UPDATE mytable SET my_description = 'FRED' WHERE my_key = 'RGM'" Dim cmd As New IBM.Data.Informix.IfxCommand(strsql, Conn) cmd.ExecuteNonQuery() with the record you are trying to update locked then the timeout happens after about 35 seconds (not 15 as you might expect). You cannot set the ConnectionTimeout property in code but you can set it in the connect string by appending "; Timeout=nn" to it (where nn is the timeout in seconds). This is the same parameter as is used by SQL Server. This will affect the value of the ConnectionTimeout property as we can display it. However it has NO EFFECT WHATSOEVER on the actual Timeout used by the connection ! Any ideas or thoughts gratefully received, Richard Moon (MCSD)

Responses interspersed. richard@richardmoon.com (Richard Moon) wrote in message news:<9e0b27c2.0411040751.77e9603a@posting.google.com>... > I'm also having timeout problems using the IBM.Data.Informix classes. > The release notes that came with the SDK say it is 2.81 UC3. _U_C3 would be a typo/mistake since .Net only exist on the Windows platform and Informix should use a T to designate Windows platforms NT and beyond. At least, they use U for UNIX. However, 2.81.TC3 is the first and only GA release where the provider is available, as yet. > > I think there's a deeper problem - I think these are not 'real' > timeouts. > > The timeout is happening in a simple query that takes 3 seconds to run > from isql during the day (when the server is busy) but causes a > timeout error when run in a .NET Windows Service during the evening > (when the server is quiet). > > We've tried it at different times of the night so we're pretty sure > it's not a genuine timeout problem. It does not clash with an archive > or anything similar. > > We think there's a bug in the IBM.Data.Informix classes. The database > is IDS 7.2. > I'm not sure what you are saying. Are you getting a timeout message from the Windows Service, the provider, or something else? When you say these are not 'real' timeouts, do you mean that the timeouts are not working or that what is reported as a timeout error is really something else? If you run the same query through a .Net app outside of a service environment what happens? > Interestingly it seems there is a ConnectionTimout property which you > can get from the IFXConnection object, for example > > Dim Conn As New IBM.Data.Informix.IfxConnection("your connect > string") > Conn.Open() > Debug.WriteLine("Timeout : " & Conn.ConnectionTimeout) > > With a normal connection string this displays the value 15. > > Now if you run a command like the following > Dim strsql As String = _ > "set lock mode to wait; UPDATE mytable SET my_description = > 'FRED' WHERE my_key = 'RGM'" > Dim cmd As New IBM.Data.Informix.IfxCommand(strsql, Conn) > cmd.ExecuteNonQuery() > > with the record you are trying to update locked then the timeout > happens after about 35 seconds (not 15 as you might expect). Couple of things: a) the ConnectionTimeout setting refers to the time allowed to the provider to establish a connection to the server, _not_ the time allowed a query to run. They are different settings. b) Having said that, I do think there are real problems in the provider's timeout settings for both connection and command. > > You cannot set the ConnectionTimeout property in code but you can set > it in the connect string by appending "; Timeout=nn" to it (where nn > is the timeout in seconds). This is the same parameter as is used by > SQL Server. > > This will affect the value of the ConnectionTimeout property as we can > display it. > > However it has NO EFFECT WHATSOEVER on the actual Timeout used by the > connection ! > 170027 CONNECTIONTIMEOUT IS NOT PROPERLY SUPPORTED. IT SHOULD ALLOW A CONNECTION TO WAIT UNTIL SOME OTHER THREAD HAS RELEASED A CONNECTION FOR USE Should be fixed at the 2.90 release. Problem is there doesn't appear to be a clear distinction between application induced reasons for waiting and lower-level induced reasons for waiting. For instance, say an multi-threaded application has bumped into the limit set by Max Pool Size; presumably you'd want a setting for allowing the provider to wait until a similar connection is closed before returning an error. The setting of MaxPoolSize and the number of connections opened at one time is controlled entirely by the application; so, the mechanism within the provider for handling this is going to be different from the mechanism for how long to wait for a response after sending a connect request over the network. Probably a lot of application programmers don't care about the distinction, but it exists nonetheless. I guess the provider could first wait for a connection object to become available and then subtract the time that it waited for that from the original timeout in order to tell the network communication module how long it is willing to wait. It's still a young product and I wouldn't be surprised if not all this is hooked together yet. My experience with the timeouts in the this provider is that either they work as expected or they have no effect at all, as your note above. So, if you are seeing errors that are carry a message about timeout, I kind of suspect that something else is going wrong (a lock, bad connection setting, other) and is merely being reported as a timeout because some module gets tired of waiting. Can't tell offhand what module that might be. Turning on tracing in the provider might help; it's in the manual. Getting the service to recognise the environment settings might not be entirely straightforward. > Any ideas or thoughts gratefully received, > > > Richard Moon > (MCSD) Hope this helps a little, Chris

> However it has NO EFFECT WHATSOEVER on the actual Timeout used by the > connection ! > > Any ideas or thoughts gratefully received, A bit after the original post, but there is an answer: use the IfxCommand object's CommandTimeout Property. Not documented anywhere that I have found, but it defaults to 30 (seconds). Set it up to something higher, like 300 or 600. Note: I'll be doing a session on ADO.Net and Informix at the IDUG/IIUG conference in May. Would love to have some .Net folks there. *I'll* probably learn something! Sean Durity