Re: Missing informix error messages
On Thu, Jan 14, 2010 at 7:41 PM, Jonathan Leffler jonathan.leff...@gmail.com wrote: On Thu, Jan 14, 2010 at 8:49 AM, m. allan noah kitno...@gmail.com wrote: I have a problem with some fastcgi scripts which use DBD::Informix. I trust this is DBD::Informix 2008.0513 and not some earlier version. correct. Which version of Perl are you using? 5.8.8 (IA64.ARCHREV_0-thread-multi-LP64) Which platform are you running on? HPUX 11.31 Itanium Which version of Informix ClientSDK (ESQL/C) are you using? esql -V IBM Informix CSDK Version 3.50, IBM Informix-ESQL Version 3.50.FC3 Fastcgi is like regular cgi, except the script does not exit after the request is complete, it loops back to the beginning, and waits for a new request. This significantly improves performance for scripts with large startup penalties. The scripts are single threaded, with apache spawning new copies as required. I am connecting and disconnecting from the db on each request. Everything works fine, except that sql error messages can only be found on the first pass thru the fastcgi loop. e.g. DBD::Informix::st execute failed: SQL: -268: Unique constraint (informix.u116_31) violated. ISAM: -100: ISAM error: duplicate value for a record with unique key. On the subsequent passes i get: DBD::Informix::st execute failed: SQL: -268: Failed to locate SQL error message ISAM: -100: Failed to locate ISAM error message I've not seen that behaviour before that I recall. How reliable is it? 100%? Sometimes? Seldom but often enough to be annoying? 100% reliable. The first pass thru the loop has access to the messages, all subsequent passes do not. This happens even if the first pass does not generate an error. I have dumped the environment on both passes, and they are identical, including all the informix vars. I cannot reproduce this issue with a command line script, so I might have to ask some apache/fastcgi hackers too, but I thought I would start here. Normally, once the code has found the error messages once, there is no further problem. It is very unusual - indeed, I'm not sure I have any explanation of a mechanism by which it can happen. I've also used Env::C to dump the 'C' environment, and those vars are also the same on each pass. I'm at a loss otherwise. The best I can come up with as a 'debugging' mechanism is to suggest that you add tracing to the system - DBI_TRACE=3 (or higher) in the environment or an equivalent. Offhand, I'm not sure where the output would go with FastCGI in the system; you might need to work on the output file too. I will try this and report back. Thanks! allan -- The truth is an offense, but not a sin
Re: Missing informix error messages
On Tue, Jan 19, 2010 at 11:06 AM, m. allan noah kitno...@gmail.com wrote: On Thu, Jan 14, 2010 at 7:41 PM, Jonathan Leffler jonathan.leff...@gmail.com wrote: On Thu, Jan 14, 2010 at 8:49 AM, m. allan noah kitno...@gmail.com wrote: I have a problem with some fastcgi scripts which use DBD::Informix. I trust this is DBD::Informix 2008.0513 and not some earlier version. correct. Which version of Perl are you using? 5.8.8 (IA64.ARCHREV_0-thread-multi-LP64) Which platform are you running on? HPUX 11.31 Itanium Which version of Informix ClientSDK (ESQL/C) are you using? esql -V IBM Informix CSDK Version 3.50, IBM Informix-ESQL Version 3.50.FC3 Fastcgi is like regular cgi, except the script does not exit after the request is complete, it loops back to the beginning, and waits for a new request. This significantly improves performance for scripts with large startup penalties. The scripts are single threaded, with apache spawning new copies as required. I am connecting and disconnecting from the db on each request. Everything works fine, except that sql error messages can only be found on the first pass thru the fastcgi loop. e.g. DBD::Informix::st execute failed: SQL: -268: Unique constraint (informix.u116_31) violated. ISAM: -100: ISAM error: duplicate value for a record with unique key. On the subsequent passes i get: DBD::Informix::st execute failed: SQL: -268: Failed to locate SQL error message ISAM: -100: Failed to locate ISAM error message I've not seen that behaviour before that I recall. How reliable is it? 100%? Sometimes? Seldom but often enough to be annoying? 100% reliable. The first pass thru the loop has access to the messages, all subsequent passes do not. This happens even if the first pass does not generate an error. I have dumped the environment on both passes, and they are identical, including all the informix vars. I cannot reproduce this issue with a command line script, so I might have to ask some apache/fastcgi hackers too, but I thought I would start here. Normally, once the code has found the error messages once, there is no further problem. It is very unusual - indeed, I'm not sure I have any explanation of a mechanism by which it can happen. I've also used Env::C to dump the 'C' environment, and those vars are also the same on each pass. I'm at a loss otherwise. The best I can come up with as a 'debugging' mechanism is to suggest that you add tracing to the system - DBI_TRACE=3 (or higher) in the environment or an equivalent. Offhand, I'm not sure where the output would go with FastCGI in the system; you might need to work on the output file too. I will try this and report back. And, setting $dbh-trace(10,'/tmp/foo') yields the same output for both passes, with the exception of the error messages. I'm left scratching my head here, but I'll keep trying to reproduce it at the command line. allan -- The truth is an offense, but not a sin
Missing informix error messages
I have a problem with some fastcgi scripts which use DBD::Informix. Fastcgi is like regular cgi, except the script does not exit after the request is complete, it loops back to the beginning, and waits for a new request. This significantly improves performance for scripts with large startup penalties. The scripts are single threaded, with apache spawning new copies as required. I am connecting and disconnecting from the db on each request. Everything works fine, except that sql error messages can only be found on the first pass thru the fastcgi loop. e.g. DBD::Informix::st execute failed: SQL: -268: Unique constraint (informix.u116_31) violated. ISAM: -100: ISAM error: duplicate value for a record with unique key. On the subsequent passes i get: DBD::Informix::st execute failed: SQL: -268: Failed to locate SQL error message ISAM: -100: Failed to locate ISAM error message I have dumped the environment on both passes, and they are identical, including all the informix vars. I cannot reproduce this issue with a command line script, so I might have to ask some apache/fastcgi hackers too, but I thought I would start here. allan -- The truth is an offense, but not a sin
Re: Missing informix error messages
On Thu, Jan 14, 2010 at 8:49 AM, m. allan noah kitno...@gmail.com wrote: I have a problem with some fastcgi scripts which use DBD::Informix. I trust this is DBD::Informix 2008.0513 and not some earlier version. Which version of Perl are you using? Which platform are you running on? Which version of Informix ClientSDK (ESQL/C) are you using? Fastcgi is like regular cgi, except the script does not exit after the request is complete, it loops back to the beginning, and waits for a new request. This significantly improves performance for scripts with large startup penalties. The scripts are single threaded, with apache spawning new copies as required. I am connecting and disconnecting from the db on each request. Everything works fine, except that sql error messages can only be found on the first pass thru the fastcgi loop. e.g. DBD::Informix::st execute failed: SQL: -268: Unique constraint (informix.u116_31) violated. ISAM: -100: ISAM error: duplicate value for a record with unique key. On the subsequent passes i get: DBD::Informix::st execute failed: SQL: -268: Failed to locate SQL error message ISAM: -100: Failed to locate ISAM error message I've not seen that behaviour before that I recall. How reliable is it? 100%? Sometimes? Seldom but often enough to be annoying? I have dumped the environment on both passes, and they are identical, including all the informix vars. I cannot reproduce this issue with a command line script, so I might have to ask some apache/fastcgi hackers too, but I thought I would start here. Normally, once the code has found the error messages once, there is no further problem. It is very unusual - indeed, I'm not sure I have any explanation of a mechanism by which it can happen. The best I can come up with as a 'debugging' mechanism is to suggest that you add tracing to the system - DBI_TRACE=3 (or higher) in the environment or an equivalent. Offhand, I'm not sure where the output would go with FastCGI in the system; you might need to work on the output file too. -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
