 |
 |
 |
 |
|
|
Date: 12/28/00
- Next message: rainbow178 <email protected>: "[PHP-DEV] PHP 4.0 Bug #8475: Cannot login to Oracle database"
- Previous message: arnoldg <email protected>: "[PHP-DEV] PHP 4.0 Bug #8484: Compiling of php_odbc.c Fails"
- Next in thread: Peter Kocks: "RE: [PHP-DEV] PHP/Informix -439 error"
- Reply: Peter Kocks: "RE: [PHP-DEV] PHP/Informix -439 error"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hello all,
as you know, we have a problem. This one is a biggie, it's been around for a while, and is a show stopper for many sites
trying to use PHP/Informix in production.
I attached to this message emails I collected on the subject so far. Previous entries in PHP bug database mysteriously
disappeared, and I can now find only two now:
http://bugs.php.net/bugs.php?id=4468
http://bugs.php.net/bugs.php?id=8267
Things I'm sure of:
1) Some sites get this often, some not at all, even at heavy load.
2) Heavy load is necessary to get this error
3) It can happen in both 7.3 and 9.x engines
4) I managed to reproduce this only once, and never again, and have no idea why.
Things I'm guessing:
a) It's a ESQL/C coding problem, related to verifying that the connection is not currently in use.
b) It's an ESQL/C coding problem, and we will need to look to threading as an alternative to signals, and rewrite
Informix PHP driver.
c) It's not ESQL/C coding problem at all, but bug in certain versions of Informix - ESQL/C, and this is the reason some
installations never get this. It appears that very few people with old versions of CSDK get this. Most people
complaining have 9.x servers.
I would appreciate if anybody can add more recent experiences with this, and if all of you can please report versions of
PHP, OS, IDS, and ESQL/C.
Especially appreciated is all help we can get from our friends in Informix, and it would be nice if you guys can take a
look at change log and bug database for ESQL/C in last 12 months or so, talking about -439. Would it be possible to get
someone from ESQL/C team to take a look at this?
I wish you all happy and -439 error free New Year!
Yours, Andrej Falout, www.falout.com/IspeakForMyself.html
"For ideas, fame _is_ fortune. And nothing makes you famous faster
then an audience willing to distribute your work for free."
- John Perry Barlow, Wired 8.10
attached mail follows:
From: mischoi <email protected>
Operating system: Linux
PHP version: 4.0.3pl1
PHP Bug Type: Informix related
Bug description: Warning: ifx_pconnect : E [SQLSTATE=IX 000 SQLCODE=-439]
Warning: ifx_pconnect : E [SQLSTATE=IX 000 SQLCODE=-439]
--------------------------------------------------------
I don't use [ifx_pconnect] function in my scripts.
The reasons of -439 error code are as follows.(finderr -439)
(I can't understand the means of thr descriptions.)
--------------------------------------------------------
You attempted to call an SQL routine or attempted to execute an SQL
statement within a signal handling function/routine or a callback
function/procedure. Use only the sqldone() and sqlbreak() library
functions inside your INFORMIX-ESQL/C callback function. Use only the
ECO-SQD and ECO-SQB library routines inside your ESQL/COBOL callback
procedure. In addition, if you want to unregister your callback
function in INFORMIX-ESQL/C, you can invoke the sqlbreakcallback()
callback registration function within your callback procedure. If you
want to unregister your callback procedure in ESQL/COBOL, you can
invoke the ECO-SQBCB callback registration routine within your callback
procedure.
------------------------------------------------------------
-- Edit Bug report at: http://bugs.php.net/?id=8267&edit=1-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe <email protected> For additional commands, e-mail: php-dev-help <email protected> To contact the list administrators, e-mail: php-list-admin <email protected>
attached mail follows:
We had the same problem and we had to call a "guru" from Informix France. It does 3 months we still have only very few errors (I thought the problem was fixed but I've just talked to the client and he says that sometimes this problem appears. I need to verify that). Anyway, we have seen that when we stop/start Apache, the problem disappears most of the time.
regards, Patrick Grenier.
Systems developer Framfab France www.framfab.fr Messagerie : pgrenier <email protected> T. +33(0)1.55.48.11.00 - F. +33(0)1.47.35.00.00 ----- Original Message ----- From: Andrej Falout <afalout <email protected>> To: Ian Layton <ian.layton <email protected>>; PHP Install List <php-install <email protected>>; PHP General List <php-general <email protected>>; PHP Dev List <php-dev <email protected>>; PHP DB List <php-db <email protected>> Cc: <danny.heijl <email protected>>; <jleffler <email protected>>; <pgrenier <email protected>>; <novicky <email protected>> Sent: Sunday, August 27, 2000 3:07 AM Subject: RE: [PHP-DEV] PHP4 and Informix issues
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > ....another one > > Can you please look for bug #4468: "random ifx_pconnect code -439 > withifx_connect" and associated discussion in the list archives? > > Hey guys on CC line; anything new to say? This is obviously a > problem... > > Reminder for -439: > > Database server is currently processing an SQL task. > > You attempted to call an SQL routine or attempted to execute an SQL > statement within a signal handling function/routine or a callback > function/procedure. Use only the sqldone() and sqlbreak() library > functions inside your INFORMIX-ESQL/C callback function. Use only the > ECO-SQD and ECO-SQB library routines inside your ESQL/COBOL callback > procedure. In addition, if you want to unregister your callback > function in INFORMIX-ESQL/C, you can invoke the sqlbreakcallback() > callback registration function within your callback procedure. If you > want to unregister your callback procedure in ESQL/COBOL, you can > invoke the ECO-SQBCB callback registration routine within your > callback procedure. > > Yours, Andrej Falout, http://www.falout.com ICQ 7628616 > #----------------------------------------------------------------- > globals "I_speak_for_myself.4gl" > > "I didn't know what I was doing. A blood vessel in my brain must > have burst" - Chief of police in Hesse, Germany, after he was > caught shoplifting ant poison worth a few dollars. > > > -----Original Message----- > > From: Ian Layton [mailto:ian.layton <email protected>] > > Sent: Friday, 25 August 2000 5:25 > > To: PHP Install List; PHP General List; PHP Dev List; PHP DB List > > Subject: [PHP-DEV] PHP4 and Informix issues > > > > > > We are currently trying to use Informix Dynamic Server 2000 Version > 9.20.UC1 > > with PHP Version 4.0PR2. We are running into trouble with PHP's > connection > > to Informix. How we have it currently is using ifx_connect with > persistent > > connections turned off in the php.ini file with the line: > > > > ifx.allow_persistent = Off ; allow or prevent > > persistent link > > > > PHP apparently has a bug in the system where it does not look in the > php.ini > > files because PHP is still trying to use persistent connections on > the > > system. About 1/3 of the time we try to set up a database > connection, the > > following error occurs: > > > > Warning: ifx_pconnect : E [SQLSTATE=IX 000 SQLCODE=-439] in > ../sql.inc on > > line 28 > > Database server is currently processing SQL task. > > > > sql.inc line 28 reads as follows: > > > > if(! ($DBH = ifx_connect($InforData,$InforUser,$InforPass))) > > > > We are currently closing all db connection with ifx_close at the end > of > > every script. I have heard that ifx_connect is basically like > ifx_pconnect. > > Is that true even when persistent connections are turned off in the > ini > > file? Also, has anyone else come across this problem and a possible > > workaround for it? > > > > The site we are working on can expect upwards of a thousand database > hits > > per minute. Right now, this is not possible as a single debugger can > not be > > on the system without it bringing up the error. Any help anyone can > lend us > > on this would be greatly appreciated. > > > > Thank you > > Ian Layton > > Linuxhpc.com > > > > > > -- > > PHP Development Mailing List <http://www.php.net/> > > To unsubscribe, e-mail: php-dev-unsubscribe <email protected> > > For additional commands, e-mail: php-dev-help <email protected> > > To contact the list administrators, e-mail: > php-list-admin <email protected> > > > > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 6.0.2i > > iQA/AwUBOae/DBZH34ibpTRkEQIpiACfTbS3zR5AsWjjmbYRQ27TqSlriDgAoOMA > I5roIwSIw2hL/E+oIoQo+YU4 > =Ykbs > -----END PGP SIGNATURE----- > >
attached mail follows:
We are currently trying to use Informix Dynamic Server 2000 Version 9.20.UC1 with PHP Version 4.0PR2. We are running into trouble with PHP's connection to Informix. How we have it currently is using ifx_connect with persistent connections turned off in the php.ini file with the line:
ifx.allow_persistent = Off ; allow or prevent persistent link
PHP apparently has a bug in the system where it does not look in the php.ini files because PHP is still trying to use persistent connections on the system. About 1/3 of the time we try to set up a database connection, the following error occurs:
Warning: ifx_pconnect : E [SQLSTATE=IX 000 SQLCODE=-439] in ../sql.inc on line 28 Database server is currently processing SQL task.
sql.inc line 28 reads as follows:
if(! ($DBH = ifx_connect($InforData,$InforUser,$InforPass)))
We are currently closing all db connection with ifx_close at the end of every script. I have heard that ifx_connect is basically like ifx_pconnect. Is that true even when persistent connections are turned off in the ini file? Also, has anyone else come across this problem and a possible workaround for it?
The site we are working on can expect upwards of a thousand database hits per minute. Right now, this is not possible as a single debugger can not be on the system without it bringing up the error. Any help anyone can lend us on this would be greatly appreciated.
Thank you Ian Layton Linuxhpc.com
-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe <email protected> For additional commands, e-mail: php-dev-help <email protected> To contact the list administrators, e-mail: php-list-admin <email protected>
attached mail follows:
As far as I know, there can be as many simultaneous connections with the same user id, password and host as you like, as long as they are in different processes. It is different if you use a multithreading architecture, but this is not the case with Apache 1.3.x or PHP in CGI mode on Win32.
The only problem could theoretically be several processes using the same "connection identifier", but there is no mention of this in the ESQL/C manuals, and my experience both on Linux, SVR4 Unix and Windows NT has shown that this is no problem on those platforms with IDS 7.2x, IDS 7.3x and IDS 2000.
I have done tests with the Apache benchmark program (ab) requesting the same page with 50 concurrent requests 10000 times and could not reproduce the error. There were 60 or 70 Apache processes all using the same user id, password, host, database and connection identifiers concurrently.
I would need a lot more information, sample php code etc.. in order to try to reproduce the problem. And even then it could still be platform specific, and I only have access to the three mentioned above.
Regards,
Danny
--- ----- Original Message ----- From: "Andrej Falout" <afalout <email protected>> To: <danny.heijl <email protected>> Sent: Saturday, June 17, 2000 3:46 AM Subject: FW: Bug #4468: random ifx_pconnect code -439 withifx_connect> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Danny, > > FYI. Jonathan Leffler is closest you can get to Greek version of > Informix-specific God. > > Now that I looked at it, really, how do you verify connection is not > in use? > > I know pconenct is supposed to reuse connections, and there is also > the case of "user friendly" "let's try to use last open connection if > one was not specified", but what effect this have on more then one > process, I'm not sure. > > What do you say? > > Yours, Andrej Falout, http://www.falout.com ICQ 7628616 > #----------------------------------------------------------------- > globals "std_disclaimer.4gl" > > "Venus is still under construction. Thank you for your patience > and we apologize for the inconvenience." - Match.com online dating > site. > > > > - -----Original Message----- > From: Jonathan Leffler [mailto:jleffler <email protected>] > Sent: Saturday, 17 June 2000 9:01 > To: afalout <email protected> > Subject: Re: FW: [PHP-DEV] Bug #4468: random ifx_pconnect code -439 > withifx_connect > > > On Fri, 26 May 2000, Andrej Falout wrote: > >Dear Jonathan, > > > >I hope you will forgive me for contacting you directly. Danny Heijl > >and me are members of PHP development team. We are experiencing > >problem described later, related to Informix ESQL/C and are not sure > >how to interpret this. > > You aren't forgotten! > > >I tried calling support, but they have very few references to error > >- -439 in there database. Also attached is code for Informix PHP > >interface. > > > >Since I know you are the expert in this field, all PHP/Informix > >community would be grateful to you if you would take a look and maybe > >suggest where to start. > > It's not particularly easy to follow the code. The bug report is > specifically to do with ifx_pconnect(), so the first section of the > first function should be what needs scrutiny. Now, I can see where > you > look to see whether there is a connection for the same database/host, > user and password, but I don't see where you verify whether that > connection is in use at the moment. So, if you time it right and the > same host/user/password combination is requested at the same time, > then > you might end up with two processes both trying to use the same > connection, which won't work and will yield -439. > > Now, what am I overlooking? Where do you verify that the connection > is > not currently in use? > > >- -----Original Message----- > >From: Danny Heijl [mailto:danny.heijl <email protected>] > >Sent: Sunday, 21 May 2000 9:36 > >To: afalout <email protected>; pgrenier <email protected>; php-dev <email protected> > >Subject: Re: [PHP-DEV] Bug #4468: random ifx_pconnect code -439 with > >ifx_connect > > > > > >As there are no signal handling routines in the php_ifx driver (it is > >all strictly synchronous) I am beginning to suspect a problem in the > >ESQL/C libraries when a lot of connecting/disconnecting is going on. > > > >Perhaps internal ESQL/C data structures are not getting released > >immediately and make the ESQL/C libraries complain when the *same > >process* tries to reopen the same connection that was closed only > >milliseconds ago. > > > >I have several production sites running Apache/modphp3/Informix on > >SVR4.0 Unix machines and have never experienced this error. They use > >both local databases (using Streams Pipes IPC connections) and > >databases on other machines (using TLI TCP connections ). > > > >But we *always* use persistent connections and force freeing of all > >result sets (the ifx_ functions are wrapped in database/recordset > >classes and are never called directly). As an aside, I can see no > >obvious reasons for not using persistent connections. > > > >We have the same apps running on Windows NT 4 / IIS 4 with php 3.0.14 > >as CGI too, no problems there either. But in CGI mode it is of > course > >*another* process that is opening that connection again. > > > >Perhaps our load is not big enough? Or the Informix libraries (IDS > >7.22, IDS 7.23, or IDS 7.31, all with CSDK 2.30) on Windows and NCR > >MP-RAS Unix do not have this problem? > > > >Danny > >- --- > > > >- ----- Original Message ----- > >From: "Andrej Falout" <afalout <email protected>> > >To: <pgrenier <email protected>>; <php-dev <email protected>> > >Cc: <Danny.Heijl <email protected>> > >Sent: Sunday, May 21, 2000 8:46 AM > >Subject: RE: [PHP-DEV] Bug #4468: random ifx_pconnect code -439 with > >ifx_connect > > > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> I was stress testing our installation, and on heavy CPU load we do > get > >> this too. > >> > >> - -439 > >> > >> Database server is currently processing an SQL task. > >> > >> You attempted to call an SQL routine or attempted to execute an SQL > >> statement within a signal handling function/routine or a callback > >> function/procedure. Use only the sqldone() and sqlbreak() library > >> functions inside your INFORMIX-ESQL/C callback function. In > >> addition, if you want to unregister your callback function in > >> INFORMIX-ESQL/C, you can invoke the sqlbreakcallback() callback > >> registration function within your callback procedure. > >> > >> I went trough all the usual suspects in ONCONFIG, but did not > manage > >> to get rid of it. From code description, it would look like problem > in > >> ESQL code of PHP Informix interface. > > Yes, it is a client-side (meaning PHP) problem rather than a server > side > problem. I wouldn't expect the ONCONFIG file to solve it at all. > > >> ifx.allow_persistent seems to reduce this, so I was playing with > >> NETTYPE, but nothing definitive. Granted, I was really STRESSING > the > >> box. Are you closing your connections when finished, and freeing > the > >> results? > >> > >> > >> > -----Original Message----- > >> > From: pgrenier <email protected> [mailto:pgrenier <email protected>] > >> > Sent: Wednesday, 17 May 2000 1:24 > >> > To: php-dev <email protected> > >> > Subject: [PHP-DEV] Bug #4468: random ifx_pconnect code -439 with > ifx_connect > >> > > >> > > >> > From: pgrenier <email protected> > >> > Operating system: linux red hat 6.0 > >> > PHP version: 3.0.14 > >> > PHP Bug Type: Other > >> > Bug description: random ifx_pconnect code -439 with ifx_connect > >> > > >> > configure php : > >> > #!/bin/bash > >> > CC="gcc" OPTIM="-O2" \ > >> > ./configure \ > >> > --includedir=/opt/informix/incl/esql \ > >> > --with-apache=/www/install/apache_1.3.11 \ > >> > --with-informix=/opt/informix \ > >> > --with-zlib \ > >> > --enable-sysvsem \ > >> > --enable-sysvshm \ > >> > --enable-track-vars \ > >> > --enable-magic-quotes > >> > > >> > a piece of php3.ini : > >> > [Informix] > >> > ifx.default_host = ; default host > >> > for ifx_connect() (doesn't apply in safe mode) > >> > ifx.default_user = ; default user > >> > for ifx_connect() (doesn't apply in safe mode) > >> > ifx.default_password = ; default > >> > password for ifx_connect() (doesn't apply in safe mode) > >> > ifx.allow_persistent = Off ; allow or > >> > prevent persistent link > >> > ifx.max_persistent = -1 ; maximum number > >> > of persistent links. -1 means no limit > >> > ifx.max_links = -1 ; maximum number > >> > of links (persistent+non persistent). -1 means no limit > >> > ifx.textasvarchar = 0 ; if set on, > >> > select statements return the contents of a text blob instead of > it's id > >> > ifx.byteasvarchar = 0 ; if set on, > >> > select statements return the contents of a byte blob instead of > it's id > >> > ifx.charasvarchar = 0 ; trailing blanks > >> > are stripped from fixed-length char columns. May help the life > >> > ; of Informix SE > users. > >> > ifx.blobinfile = 0 ; if set on, the > >> > contents of text&byte blobs are dumped to a file instead of > >> > ; keeping them in > memory > >> > ifx.nullformat = 0 ; NULL's are > >> > returned as empty strings, unless this is set to 1. In that case, > >> > ; NULL's are > returned as string 'NULL'. > > - -- > Yours, > Jonathan Leffler (Jonathan.Leffler <email protected>) #include > <disclaimer.h> > Guardian of DBD::Informix v1.00.PC1 -- http://www.perl.com/CPAN > "I don't suffer from insanity; I enjoy every minute of it!" > > > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 6.0.2i > > iQA/AwUBOUouchZH34ibpTRkEQJVTgCfaou4tfxifxTWom3GOG17qInKbREAniEJ > CpH0jIwv1mOKp52iOYTQj6gO > =65D+ > -----END PGP SIGNATURE----- > >
attached mail follows:
On Fri, 26 May 2000, Andrej Falout wrote: >Dear Jonathan, > >I hope you will forgive me for contacting you directly. Danny Heijl >and me are members of PHP development team. We are experiencing >problem described later, related to Informix ESQL/C and are not sure >how to interpret this.
You aren't forgotten!
>I tried calling support, but they have very few references to error >- -439 in there database. Also attached is code for Informix PHP >interface. > >Since I know you are the expert in this field, all PHP/Informix >community would be grateful to you if you would take a look and maybe >suggest where to start.
It's not particularly easy to follow the code. The bug report is specifically to do with ifx_pconnect(), so the first section of the first function should be what needs scrutiny. Now, I can see where you look to see whether there is a connection for the same database/host, user and password, but I don't see where you verify whether that connection is in use at the moment. So, if you time it right and the same host/user/password combination is requested at the same time, then you might end up with two processes both trying to use the same connection, which won't work and will yield -439.
Now, what am I overlooking? Where do you verify that the connection is not currently in use?
>- -----Original Message----- >From: Danny Heijl [mailto:danny.heijl <email protected>] >Sent: Sunday, 21 May 2000 9:36 >To: afalout <email protected>; pgrenier <email protected>; php-dev <email protected> >Subject: Re: [PHP-DEV] Bug #4468: random ifx_pconnect code -439 with >ifx_connect > > >As there are no signal handling routines in the php_ifx driver (it is >all strictly synchronous) I am beginning to suspect a problem in the >ESQL/C libraries when a lot of connecting/disconnecting is going on. > >Perhaps internal ESQL/C data structures are not getting released >immediately and make the ESQL/C libraries complain when the *same >process* tries to reopen the same connection that was closed only >milliseconds ago. > >I have several production sites running Apache/modphp3/Informix on >SVR4.0 Unix machines and have never experienced this error. They use >both local databases (using Streams Pipes IPC connections) and >databases on other machines (using TLI TCP connections ). > >But we *always* use persistent connections and force freeing of all >result sets (the ifx_ functions are wrapped in database/recordset >classes and are never called directly). As an aside, I can see no >obvious reasons for not using persistent connections. > >We have the same apps running on Windows NT 4 / IIS 4 with php 3.0.14 >as CGI too, no problems there either. But in CGI mode it is of course >*another* process that is opening that connection again. > >Perhaps our load is not big enough? Or the Informix libraries (IDS >7.22, IDS 7.23, or IDS 7.31, all with CSDK 2.30) on Windows and NCR >MP-RAS Unix do not have this problem? > >Danny >- --- > >- ----- Original Message ----- >From: "Andrej Falout" <afalout <email protected>> >To: <pgrenier <email protected>>; <php-dev <email protected>> >Cc: <Danny.Heijl <email protected>> >Sent: Sunday, May 21, 2000 8:46 AM >Subject: RE: [PHP-DEV] Bug #4468: random ifx_pconnect code -439 with >ifx_connect > > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> I was stress testing our installation, and on heavy CPU load we do get >> this too. >> >> - -439 >> >> Database server is currently processing an SQL task. >> >> You attempted to call an SQL routine or attempted to execute an SQL >> statement within a signal handling function/routine or a callback >> function/procedure. Use only the sqldone() and sqlbreak() library >> functions inside your INFORMIX-ESQL/C callback function. In >> addition, if you want to unregister your callback function in >> INFORMIX-ESQL/C, you can invoke the sqlbreakcallback() callback >> registration function within your callback procedure. >> >> I went trough all the usual suspects in ONCONFIG, but did not manage >> to get rid of it. From code description, it would look like problem in >> ESQL code of PHP Informix interface.
Yes, it is a client-side (meaning PHP) problem rather than a server side problem. I wouldn't expect the ONCONFIG file to solve it at all.
>> ifx.allow_persistent seems to reduce this, so I was playing with >> NETTYPE, but nothing definitive. Granted, I was really STRESSING the >> box. Are you closing your connections when finished, and freeing the >> results? >> >> >> > -----Original Message----- >> > From: pgrenier <email protected> [mailto:pgrenier <email protected>] >> > Sent: Wednesday, 17 May 2000 1:24 >> > To: php-dev <email protected> >> > Subject: [PHP-DEV] Bug #4468: random ifx_pconnect code -439 with ifx_connect >> > >> > >> > From: pgrenier <email protected> >> > Operating system: linux red hat 6.0 >> > PHP version: 3.0.14 >> > PHP Bug Type: Other >> > Bug description: random ifx_pconnect code -439 with ifx_connect >> > >> > configure php : >> > #!/bin/bash >> > CC="gcc" OPTIM="-O2" \ >> > ./configure \ >> > --includedir=/opt/informix/incl/esql \ >> > --with-apache=/www/install/apache_1.3.11 \ >> > --with-informix=/opt/informix \ >> > --with-zlib \ >> > --enable-sysvsem \ >> > --enable-sysvshm \ >> > --enable-track-vars \ >> > --enable-magic-quotes >> > >> > a piece of php3.ini : >> > [Informix] >> > ifx.default_host = ; default host >> > for ifx_connect() (doesn't apply in safe mode) >> > ifx.default_user = ; default user >> > for ifx_connect() (doesn't apply in safe mode) >> > ifx.default_password = ; default >> > password for ifx_connect() (doesn't apply in safe mode) >> > ifx.allow_persistent = Off ; allow or >> > prevent persistent link >> > ifx.max_persistent = -1 ; maximum number >> > of persistent links. -1 means no limit >> > ifx.max_links = -1 ; maximum number >> > of links (persistent+non persistent). -1 means no limit >> > ifx.textasvarchar = 0 ; if set on, >> > select statements return the contents of a text blob instead of it's id >> > ifx.byteasvarchar = 0 ; if set on, >> > select statements return the contents of a byte blob instead of it's id >> > ifx.charasvarchar = 0 ; trailing blanks >> > are stripped from fixed-length char columns. May help the life >> > ; of Informix SE users. >> > ifx.blobinfile = 0 ; if set on, the >> > contents of text&byte blobs are dumped to a file instead of >> > ; keeping them in memory >> > ifx.nullformat = 0 ; NULL's are >> > returned as empty strings, unless this is set to 1. In that case, >> > ; NULL's are returned as string 'NULL'.
-- Yours, Jonathan Leffler (Jonathan.Leffler <email protected>) #include <disclaimer.h> Guardian of DBD::Informix v1.00.PC1 -- http://www.perl.com/CPAN "I don't suffer from insanity; I enjoy every minute of it!"
attached mail follows:
On Fri, 26 May 2000, Andrej Falout wrote: >Dear Jonathan, > >I hope you will forgive me for contacting you directly. Danny Heijl >and me are members of PHP development team. We are experiencing >problem described later, related to Informix ESQL/C and are not sure >how to interpret this.
I'm trying to find the time to do this -- your question has not gone into a black hole. However, it isn't all that easy.
I'm actually in the process of installing PHP 4.0.0 and Apache 1.3.12 on my machine, along with MySQL as well as (obviously) Informix. I have done this before, but lost all track of what I did before (PHP 3.x), so I'm redoing it. I know that there are some issues with the build of the Informix libraries (induced by the esql script, and I've got a workaround which maybe you need to get).
Did you guys do the Informix support for PHP? And is PHP mainly done in NZ?
It is getting some visibility within Informix right at the moment, which is good.
>I tried calling support, but they have very few references to error >- -439 in there database. Also attached is code for Informix PHP >interface.
Yes, it isn't a common problem.
I'd look to threading as an alternative to signals as a way of getting into problems with this...
>Since I know you are the expert in this field, all PHP/Informix >community would be grateful to you if you would take a look and maybe >suggest where to start. > >Gratefully, > >Yours, Andrej Falout, http://www.falout.com ICQ 7628616 >#----------------------------------------------------------------- >globals "std_disclaimer.4gl" > >"Venus is still under construction. Thank you for your patience >and we apologize for the inconvenience." - Match.com online dating >site. > > > >- -----Original Message----- >From: Danny Heijl [mailto:danny.heijl <email protected>] >Sent: Sunday, 21 May 2000 9:36 >To: afalout <email protected>; pgrenier <email protected>; php-dev <email protected> >Subject: Re: [PHP-DEV] Bug #4468: random ifx_pconnect code -439 with >ifx_connect > > >As there are no signal handling routines in the php_ifx driver (it is >all >strictly synchronous) I am beginning to suspect a problem in the >ESQL/C >libraries when a lot of connecting/disconnecting is going on. > >Perhaps internal ESQL/C data structures are not getting released >immediately >and make the ESQL/C libraries complain when the *same process* tries >to >reopen the same connection that was closed only milliseconds ago. > >I have several production sites running Apache/modphp3/Informix on >SVR4.0 >Unix machines and have never experienced this error. They use both >local >databases (using Streams Pipes IPC connections) and databases on other >machines (using TLI TCP connections ). > >But we *always* use persistent connections and force freeing of all >result >sets (the ifx_ functions are wrapped in database/recordset classes and >are >never called directly). As an aside, I can see no obvious reasons for >not >using persistent connections. > >We have the same apps running on Windows NT 4 / IIS 4 with php 3.0.14 >as CGI >too, no problems there either. But in CGI mode it is of course >*another* >process that is opening that connection again. > >Perhaps our load is not big enough ? Or the Informix libraries (IDS >7.22, >IDS 7.23, or IDS 7.31, all with CSDK 2.30) on Windows and NCR MP-RAS >Unix do >not have this problem ? > >Danny >- --- > >- ----- Original Message ----- >From: "Andrej Falout" <afalout <email protected>> >To: <pgrenier <email protected>>; <php-dev <email protected>> >Cc: <Danny.Heijl <email protected>> >Sent: Sunday, May 21, 2000 8:46 AM >Subject: RE: [PHP-DEV] Bug #4468: random ifx_pconnect code -439 with >ifx_connect > > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> I was stress testing our installation, and on heavy CPU load we do >get >> this too. >> >> - -439 >> >> Database server is currently processing an SQL task. >> >> You attempted to call an SQL routine or attempted to execute an SQL >> statement within a signal handling function/routine or a callback >> function/procedure. Use only the sqldone() and sqlbreak() library >> functions inside your INFORMIX-ESQL/C callback function. In >addition, >> if you want to unregister your callback function in INFORMIX-ESQL/C, >> you can invoke the sqlbreakcallback() callback registration function >> within your callback procedure. >> >> I went trough all the usual suspects in ONCONFIG, but did not manage >> to get rid of it. From code description, it would look like problem >in >> ESQL code of PHP Informix interface. >> >> ifx.allow_persistent seems to reduce this, so I was playing with >> NETTYPE, but nothing definitive. Granted, I was really STRESSING the >> box. Are you closing your connections when finished, and freeing the >> results? >> >> Yours, Andrej Falout, http://www.falout.com ICQ 7628616 >> #----------------------------------------------------------------- >> globals "std_disclaimer.4gl" >> >> "Venus is still under construction. Thank you for your patience >> and we apologize for the inconvenience." - Match.com online dating >> site. >> >> >> >> > -----Original Message----- >> > From: pgrenier <email protected> [mailto:pgrenier <email protected>] >> > Sent: Wednesday, 17 May 2000 1:24 >> > To: php-dev <email protected> >> > Subject: [PHP-DEV] Bug #4468: random ifx_pconnect code -439 with >> > ifx_connect >> > >> > >> > From: pgrenier <email protected> >> > Operating system: linux red hat 6.0 >> > PHP version: 3.0.14 >> > PHP Bug Type: Other >> > Bug description: random ifx_pconnect code -439 with ifx_connect >> > >> > configure php : >> > #!/bin/bash >> > CC="gcc" OPTIM="-O2" \ >> > ./configure \ >> > --includedir=/opt/informix/incl/esql \ >> > --with-apache=/www/install/apache_1.3.11 \ >> > --with-informix=/opt/informix \ >> > --with-zlib \ >> > --enable-sysvsem \ >> > --enable-sysvshm \ >> > --enable-track-vars \ >> > --enable-magic-quotes >> > >> > a piece of php3.ini : >> > [Informix] >> > ifx.default_host = ; default host >> > for ifx_connect() (doesn't apply in safe mode) >> > ifx.default_user = ; default user >> > for ifx_connect() (doesn't apply in safe mode) >> > ifx.default_password = ; default >> > password for ifx_connect() (doesn't apply in safe mode) >> > ifx.allow_persistent = Off ; allow or >> > prevent persistent link >> > ifx.max_persistent = -1 ; maximum number >> > of persistent links. -1 means no limit >> > ifx.max_links = -1 ; maximum number >> > of links (persistent+non persistent). -1 means no limit >> > ifx.textasvarchar = 0 ; if set on, >> > select statements return the contents of a text blob instead of >it's >> id >> > ifx.byteasvarchar = 0 ; if set on, >> > select statements return the contents of a byte blob instead of >it's >> id >> > ifx.charasvarchar = 0 ; trailing blanks >> > are stripped from fixed-length char columns. May help the life >> > ; of Informix SE >> users. >> > ifx.blobinfile = 0 ; if set on, the >> > contents of text&byte blobs are dumped to a file instead of >> > ; keeping them in >> memory >> > ifx.nullformat = 0 ; NULL's are >> > returned as empty strings, unless this is set to 1. In that case, >> > ; NULL's are >> > returned as string 'NULL'. >> > >> > >> > -- >> > PHP Development Mailing List <http://www.php.net/> >> > To unsubscribe, e-mail: php-dev-unsubscribe <email protected> >> > For additional commands, e-mail: php-dev-help <email protected> >> > To contact the list administrators, e-mail: >> php-list-admin <email protected> >> > >> > >> -----BEGIN PGP SIGNATURE----- >> Version: PGPfreeware 6.0.2i >> >> iQA/AwUBOSbbXhZH34ibpTRkEQLY0ACeKqbSSbhz1Zi72wRqwcY9X3bYKHwAoO+h >> MD3Nnjqf4JvYySOsce/0LKkF >> =0D7N >> -----END PGP SIGNATURE----- >> >> > > >- -- >PHP Development Mailing List <http://www.php.net/> >To unsubscribe, e-mail: php-dev-unsubscribe <email protected> >For additional commands, e-mail: php-dev-help <email protected> >To contact the list administrators, e-mail: >php-list-admin <email protected> > > >-----BEGIN PGP SIGNATURE----- >Version: PGPfreeware 6.0.2i > >iQA/AwUBOS2J1BZH34ibpTRkEQLJtgCeNvYEo1jcJW2e49x0d2KO16UGJnEAoPVj >9wlSk2OV2hNAZaOmxH2mg3pn >=1q92 >-----END PGP SIGNATURE----- >
-- Yours, Jonathan Leffler (Jonathan.Leffler <email protected>) #include <disclaimer.h> Guardian of DBD::Informix v1.00.PC1 -- http://www.perl.com/CPAN "I don't suffer from insanity; I enjoy every minute of it!"
attached mail follows:
yes, I close the connection each time with ifx_close and free the results with ifx_free_result.
we tried too ifx_pconnect with php4 rc1 on one of the three web servers, without any change.
best regards, Patrick Grenier.
Systems developer Framfab France www.framfab.fr Messagerie : pgrenier <email protected> T. +33(0)1.55.48.11.00 - F. +33(0)1.47.35.00.00 ----- Original Message ----- From: Andrej Falout <afalout <email protected>> To: <pgrenier <email protected>>; <php-dev <email protected>> Cc: <Danny.Heijl <email protected>> Sent: Sunday, May 21, 2000 8:46 AM Subject: RE: [PHP-DEV] Bug #4468: random ifx_pconnect code -439 with ifx_connect
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I was stress testing our installation, and on heavy CPU load we do get > this too. > > - -439 > > Database server is currently processing an SQL task. > > You attempted to call an SQL routine or attempted to execute an SQL > statement within a signal handling function/routine or a callback > function/procedure. Use only the sqldone() and sqlbreak() library > functions inside your INFORMIX-ESQL/C callback function. In addition, > if you want to unregister your callback function in INFORMIX-ESQL/C, > you can invoke the sqlbreakcallback() callback registration function > within your callback procedure. > > I went trough all the usual suspects in ONCONFIG, but did not manage > to get rid of it. From code description, it would look like problem in > ESQL code of PHP Informix interface. > > ifx.allow_persistent seems to reduce this, so I was playing with > NETTYPE, but nothing definitive. Granted, I was really STRESSING the > box. Are you closing your connections when finished, and freeing the > results? > > Yours, Andrej Falout, http://www.falout.com ICQ 7628616 > #----------------------------------------------------------------- > globals "std_disclaimer.4gl" > > "Venus is still under construction. Thank you for your patience > and we apologize for the inconvenience." - Match.com online dating > site. > > > > > -----Original Message----- > > From: pgrenier <email protected> [mailto:pgrenier <email protected>] > > Sent: Wednesday, 17 May 2000 1:24 > > To: php-dev <email protected> > > Subject: [PHP-DEV] Bug #4468: random ifx_pconnect code -439 with > > ifx_connect > > > > > > From: pgrenier <email protected> > > Operating system: linux red hat 6.0 > > PHP version: 3.0.14 > > PHP Bug Type: Other > > Bug description: random ifx_pconnect code -439 with ifx_connect > > > > configure php : > > #!/bin/bash > > CC="gcc" OPTIM="-O2" \ > > ./configure \ > > --includedir=/opt/informix/incl/esql \ > > --with-apache=/www/install/apache_1.3.11 \ > > --with-informix=/opt/informix \ > > --with-zlib \ > > --enable-sysvsem \ > > --enable-sysvshm \ > > --enable-track-vars \ > > --enable-magic-quotes > > > > a piece of php3.ini : > > [Informix] > > ifx.default_host = ; default host > > for ifx_connect() (doesn't apply in safe mode) > > ifx.default_user = ; default user > > for ifx_connect() (doesn't apply in safe mode) > > ifx.default_password = ; default > > password for ifx_connect() (doesn't apply in safe mode) > > ifx.allow_persistent = Off ; allow or > > prevent persistent link > > ifx.max_persistent = -1 ; maximum number > > of persistent links. -1 means no limit > > ifx.max_links = -1 ; maximum number > > of links (persistent+non persistent). -1 means no limit > > ifx.textasvarchar = 0 ; if set on, > > select statements return the contents of a text blob instead of it's > id > > ifx.byteasvarchar = 0 ; if set on, > > select statements return the contents of a byte blob instead of it's > id > > ifx.charasvarchar = 0 ; trailing blanks > > are stripped from fixed-length char columns. May help the life > > ; of Informix SE > users. > > ifx.blobinfile = 0 ; if set on, the > > contents of text&byte blobs are dumped to a file instead of > > ; keeping them in > memory > > ifx.nullformat = 0 ; NULL's are > > returned as empty strings, unless this is set to 1. In that case, > > ; NULL's are > > returned as string 'NULL'. > > > > > > -- > > PHP Development Mailing List <http://www.php.net/> > > To unsubscribe, e-mail: php-dev-unsubscribe <email protected> > > For additional commands, e-mail: php-dev-help <email protected> > > To contact the list administrators, e-mail: > php-list-admin <email protected> > > > > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 6.0.2i > > iQA/AwUBOSbbXhZH34ibpTRkEQLY0ACeKqbSSbhz1Zi72wRqwcY9X3bYKHwAoO+h > MD3Nnjqf4JvYySOsce/0LKkF > =0D7N > -----END PGP SIGNATURE----- > >
-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe <email protected> For additional commands, e-mail: php-dev-help <email protected> To contact the list administrators, e-mail: php-list-admin <email protected>
attached mail follows:
As there are no signal handling routines in the php_ifx driver (it is all strictly synchronous) I am beginning to suspect a problem in the ESQL/C libraries when a lot of connecting/disconnecting is going on.
Perhaps internal ESQL/C data structures are not getting released immediately and make the ESQL/C libraries complain when the *same process* tries to reopen the same connection that was closed only milliseconds ago.
I have several production sites running Apache/modphp3/Informix on SVR4.0 Unix machines and have never experienced this error. They use both local databases (using Streams Pipes IPC connections) and databases on other machines (using TLI TCP connections ).
But we *always* use persistent connections and force freeing of all result sets (the ifx_ functions are wrapped in database/recordset classes and are never called directly). As an aside, I can see no obvious reasons for not using persistent connections.
We have the same apps running on Windows NT 4 / IIS 4 with php 3.0.14 as CGI too, no problems there either. But in CGI mode it is of course *another* process that is opening that connection again.
Perhaps our load is not big enough ? Or the Informix libraries (IDS 7.22, IDS 7.23, or IDS 7.31, all with CSDK 2.30) on Windows and NCR MP-RAS Unix do not have this problem ?
Danny
-------- Original Message ----- From: "Andrej Falout" <afalout <email protected>> To: <pgrenier <email protected>>; <php-dev <email protected>> Cc: <Danny.Heijl <email protected>> Sent: Sunday, May 21, 2000 8:46 AM Subject: RE: [PHP-DEV] Bug #4468: random ifx_pconnect code -439 with ifx_connect
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I was stress testing our installation, and on heavy CPU load we do get > this too. > > - -439 > > Database server is currently processing an SQL task. > > You attempted to call an SQL routine or attempted to execute an SQL > statement within a signal handling function/routine or a callback > function/procedure. Use only the sqldone() and sqlbreak() library > functions inside your INFORMIX-ESQL/C callback function. In addition, > if you want to unregister your callback function in INFORMIX-ESQL/C, > you can invoke the sqlbreakcallback() callback registration function > within your callback procedure. > > I went trough all the usual suspects in ONCONFIG, but did not manage > to get rid of it. From code description, it would look like problem in > ESQL code of PHP Informix interface. > > ifx.allow_persistent seems to reduce this, so I was playing with > NETTYPE, but nothing definitive. Granted, I was really STRESSING the > box. Are you closing your connections when finished, and freeing the > results? > > Yours, Andrej Falout, http://www.falout.com ICQ 7628616 > #----------------------------------------------------------------- > globals "std_disclaimer.4gl" > > "Venus is still under construction. Thank you for your patience > and we apologize for the inconvenience." - Match.com online dating > site. > > > > > -----Original Message----- > > From: pgrenier <email protected> [mailto:pgrenier <email protected>] > > Sent: Wednesday, 17 May 2000 1:24 > > To: php-dev <email protected> > > Subject: [PHP-DEV] Bug #4468: random ifx_pconnect code -439 with > > ifx_connect > > > > > > From: pgrenier <email protected> > > Operating system: linux red hat 6.0 > > PHP version: 3.0.14 > > PHP Bug Type: Other > > Bug description: random ifx_pconnect code -439 with ifx_connect > > > > configure php : > > #!/bin/bash > > CC="gcc" OPTIM="-O2" \ > > ./configure \ > > --includedir=/opt/informix/incl/esql \ > > --with-apache=/www/install/apache_1.3.11 \ > > --with-informix=/opt/informix \ > > --with-zlib \ > > --enable-sysvsem \ > > --enable-sysvshm \ > > --enable-track-vars \ > > --enable-magic-quotes > > > > a piece of php3.ini : > > [Informix] > > ifx.default_host = ; default host > > for ifx_connect() (doesn't apply in safe mode) > > ifx.default_user = ; default user > > for ifx_connect() (doesn't apply in safe mode) > > ifx.default_password = ; default > > password for ifx_connect() (doesn't apply in safe mode) > > ifx.allow_persistent = Off ; allow or > > prevent persistent link > > ifx.max_persistent = -1 ; maximum number > > of persistent links. -1 means no limit > > ifx.max_links = -1 ; maximum number > > of links (persistent+non persistent). -1 means no limit > > ifx.textasvarchar = 0 ; if set on, > > select statements return the contents of a text blob instead of it's > id > > ifx.byteasvarchar = 0 ; if set on, > > select statements return the contents of a byte blob instead of it's > id > > ifx.charasvarchar = 0 ; trailing blanks > > are stripped from fixed-length char columns. May help the life > > ; of Informix SE > users. > > ifx.blobinfile = 0 ; if set on, the > > contents of text&byte blobs are dumped to a file instead of > > ; keeping them in > memory > > ifx.nullformat = 0 ; NULL's are > > returned as empty strings, unless this is set to 1. In that case, > > ; NULL's are > > returned as string 'NULL'. > > > > > > -- > > PHP Development Mailing List <http://www.php.net/> > > To unsubscribe, e-mail: php-dev-unsubscribe <email protected> > > For additional commands, e-mail: php-dev-help <email protected> > > To contact the list administrators, e-mail: > php-list-admin <email protected> > > > > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 6.0.2i > > iQA/AwUBOSbbXhZH34ibpTRkEQLY0ACeKqbSSbhz1Zi72wRqwcY9X3bYKHwAoO+h > MD3Nnjqf4JvYySOsce/0LKkF > =0D7N > -----END PGP SIGNATURE----- > >
-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe <email protected> For additional commands, e-mail: php-dev-help <email protected> To contact the list administrators, e-mail: php-list-admin <email protected>
attached mail follows:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I was stress testing our installation, and on heavy CPU load we do get this too.
- -439
Database server is currently processing an SQL task.
You attempted to call an SQL routine or attempted to execute an SQL statement within a signal handling function/routine or a callback function/procedure. Use only the sqldone() and sqlbreak() library functions inside your INFORMIX-ESQL/C callback function. In addition, if you want to unregister your callback function in INFORMIX-ESQL/C, you can invoke the sqlbreakcallback() callback registration function within your callback procedure.
I went trough all the usual suspects in ONCONFIG, but did not manage to get rid of it. From code description, it would look like problem in ESQL code of PHP Informix interface.
ifx.allow_persistent seems to reduce this, so I was playing with NETTYPE, but nothing definitive. Granted, I was really STRESSING the box. Are you closing your connections when finished, and freeing the results?
Yours, Andrej Falout, http://www.falout.com ICQ 7628616 #----------------------------------------------------------------- globals "std_disclaimer.4gl"
"Venus is still under construction. Thank you for your patience and we apologize for the inconvenience." - Match.com online dating site.
> -----Original Message----- > From: pgrenier <email protected> [mailto:pgrenier <email protected>] > Sent: Wednesday, 17 May 2000 1:24 > To: php-dev <email protected> > Subject: [PHP-DEV] Bug #4468: random ifx_pconnect code -439 with > ifx_connect > > > From: pgrenier <email protected> > Operating system: linux red hat 6.0 > PHP version: 3.0.14 > PHP Bug Type: Other > Bug description: random ifx_pconnect code -439 with ifx_connect > > configure php : > #!/bin/bash > CC="gcc" OPTIM="-O2" \ > ./configure \ > --includedir=/opt/informix/incl/esql \ > --with-apache=/www/install/apache_1.3.11 \ > --with-informix=/opt/informix \ > --with-zlib \ > --enable-sysvsem \ > --enable-sysvshm \ > --enable-track-vars \ > --enable-magic-quotes > > a piece of php3.ini : > [Informix] > ifx.default_host = ; default host > for ifx_connect() (doesn't apply in safe mode) > ifx.default_user = ; default user > for ifx_connect() (doesn't apply in safe mode) > ifx.default_password = ; default > password for ifx_connect() (doesn't apply in safe mode) > ifx.allow_persistent = Off ; allow or > prevent persistent link > ifx.max_persistent = -1 ; maximum number > of persistent links. -1 means no limit > ifx.max_links = -1 ; maximum number > of links (persistent+non persistent). -1 means no limit > ifx.textasvarchar = 0 ; if set on, > select statements return the contents of a text blob instead of it's id > ifx.byteasvarchar = 0 ; if set on, > select statements return the contents of a byte blob instead of it's id > ifx.charasvarchar = 0 ; trailing blanks > are stripped from fixed-length char columns. May help the life > ; of Informix SE users. > ifx.blobinfile = 0 ; if set on, the > contents of text&byte blobs are dumped to a file instead of > ; keeping them in memory > ifx.nullformat = 0 ; NULL's are > returned as empty strings, unless this is set to 1. In that case, > ; NULL's are > returned as string 'NULL'. > > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, e-mail: php-dev-unsubscribe <email protected> > For additional commands, e-mail: php-dev-help <email protected> > To contact the list administrators, e-mail: php-list-admin <email protected> > > -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.0.2i
iQA/AwUBOSbbXhZH34ibpTRkEQLY0ACeKqbSSbhz1Zi72wRqwcY9X3bYKHwAoO+h MD3Nnjqf4JvYySOsce/0LKkF =0D7N -----END PGP SIGNATURE-----
-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe <email protected> For additional commands, e-mail: php-dev-help <email protected> To contact the list administrators, e-mail: php-list-admin <email protected>
attached mail follows:
From: pgrenier <email protected> Operating system: linux red hat 6.0 PHP version: 3.0.14 PHP Bug Type: Other Bug description: random ifx_pconnect code -439 with ifx_connect
configure php : #!/bin/bash CC="gcc" OPTIM="-O2" \ ./configure \ --includedir=/opt/informix/incl/esql \ --with-apache=/www/install/apache_1.3.11 \ --with-informix=/opt/informix \ --with-zlib \ --enable-sysvsem \ --enable-sysvshm \ --enable-track-vars \ --enable-magic-quotes
a piece of php3.ini : [Informix] ifx.default_host = ; default host for ifx_connect() (doesn't apply in safe mode) ifx.default_user = ; default user for ifx_connect() (doesn't apply in safe mode) ifx.default_password = ; default password for ifx_connect() (doesn't apply in safe mode) ifx.allow_persistent = Off ; allow or prevent persistent link ifx.max_persistent = -1 ; maximum number of persistent links. -1 means no limit ifx.max_links = -1 ; maximum number of links (persistent+non persistent). -1 means no limit ifx.textasvarchar = 0 ; if set on, select statements return the contents of a text blob instead of it's id ifx.byteasvarchar = 0 ; if set on, select statements return the contents of a byte blob instead of it's id ifx.charasvarchar = 0 ; trailing blanks are stripped from fixed-length char columns. May help the life ; of Informix SE users. ifx.blobinfile = 0 ; if set on, the contents of text&byte blobs are dumped to a file instead of ; keeping them in memory ifx.nullformat = 0 ; NULL's are returned as empty strings, unless this is set to 1. In that case, ; NULL's are returned as string 'NULL'.
-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe <email protected> For additional commands, e-mail: php-dev-help <email protected> To contact the list administrators, e-mail: php-list-admin <email protected>
attached mail follows:
>This seems to suggest that a signal handling routine tries to execute an >ESQL/C statement while another statement is still active. > >There are no signal handling routines or ESQL/C callback functions inside >the PHP/Informix driver, it is all strictly synchronous, so I see no obvious >cause for your problem. Unless perhaps the user hits the stop button on his >browser, Apache fires the corresponding signal to modphp aborting the >request, with the Informix code still hanging in the connect code, and a >new request is processed with the connect code still not finished. I don't >know if such a scenario is possible, I am just guessing here. > >I don't know if something similar could happen if a request hits the time >limit. >I certainly never experienced the problem, and it has not been reported >before.
We do not use ifx_close call at the end of the PHP scripts (as it is not necessary according to PHP manual). Do you think it could have any influence to this problem?
>BTW, is there a reason for not using persistent connections ? It should be a >lot faster.
The reason is that the persistent connections didn't work on our platform (Solaris 2.6). Of course we started with persistent connections but immediately after the ifx_pconnect call the httpd proccess ended with core dump. As the non-persistent connections worked fine we didn't deeply tested that problem.
I said that the problem has occured after a two month of troubleless run (with about 1000 visits a day). This would leads me to look for solving the problem in tuning the Informix server (adjustment of buffers, logs etc.) - the server seemed to slow down past few days. What do you think about it ?
Thank you
Mark
-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe <email protected> For additional commands, e-mail: php-dev-help <email protected> To contact the list administrators, e-mail: php-list-admin <email protected>
attached mail follows:
-439 : Database server is currently processing an SQL task.
"You attempted to call an SQL routine or attempted to execute an SQL statement within a signal handling function/routine or a callback function/procedure. Use only the sqldone() and sqlbreak() library functions inside your INFORMIX-ESQL/C callback function. Use only the ECO-SQD and ECO-SQB library routines inside your ESQL/COBOL callback procedure. In addition, if you want to unregister your callback function in INFORMIX-ESQL/C, you can invoke the sqlbreakcallback() callback registration function within your callback procedure. If you want to unregister your callback procedure in ESQL/COBOL, you can invoke the ECO-SQBCB callback registration routine within your callback procedure."
This seems to suggest that a signal handling routine tries to execute an ESQL/C statement while another statement is still active.
There are no signal handling routines or ESQL/C callback functions inside the PHP/Informix driver, it is all strictly synchronous, so I see no obvious cause for your problem. Unless perhaps the user hits the stop button on his browser, Apache fires the corresponding signal to modphp aborting the request, with the Informix code still hanging in the connect code, and a new request is processed with the connect code still not finished. I don't know if such a scenario is possible, I am just guessing here.
I don't know if something similar could happen if a request hits the time limit. I certainly never experienced the problem, and it has not been reported before.
BTW, is there a reason for not using persistent connections ? It should be a lot faster.
Danny
----- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe <email protected> For additional commands, e-mail: php-dev-help <email protected> To contact the list administrators, e-mail: php-list-admin <email protected>
attached mail follows:
Hello,
after a two month of perfect working, our web build on Informix + Apache with PHP started to return an SQLCODE=-439 as a result of ifx_connect. The error is returned only sometimes usually when the traffic on the server increase (the total traffic is some 1000 visits a day).
Configuration: OS Solaris 2.6 Informix IDS 7.30 Apache 1.3.9 with PHP 3.0.11 as a module
This is a quite unexpected error as this should occures only within an incorrect function call in INFORMIX-ESQL/C.
I dont know whether this error comes from a poorly tuned Informix (the onconfig file) or it is a bug in php-informix connection?
Thank you for any idea.
Mark
-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe <email protected> For additional commands, e-mail: php-dev-help <email protected> To contact the list administrators, e-mail: php-list-admin <email protected>
-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe <email protected> For additional commands, e-mail: php-dev-help <email protected> To contact the list administrators, e-mail: php-list-admin <email protected>