From: "Danny Heijl" To: References: <000e01bfd7fd$ec1cee80$0101a8c0@csi.co.nz> Subject: Re: Bug #4468: random ifx_pconnect code -439 withifx_connect Date: Sat, 17 Jun 2000 21:37:44 +1300 Organization: CEVI NV Message-ID: <000c01bfd837$4f32e680$3e9382c3@eunet.be> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal 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" To: 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@informix.com] > Sent: Saturday, 17 June 2000 9:01 > To: afalout@ihug.co.nz > 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@cevi.be] > >Sent: Sunday, 21 May 2000 9:36 > >To: afalout@ihug.co.nz; pgrenier@framfab.fr; php-dev@lists.php.net > >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" > >To: ; > >Cc: > >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@framfab.fr [mailto:pgrenier@framfab.fr] > >> > Sent: Wednesday, 17 May 2000 1:24 > >> > To: php-dev@lists.php.net > >> > Subject: [PHP-DEV] Bug #4468: random ifx_pconnect code -439 with > ifx_connect > >> > > >> > > >> > From: pgrenier@framfab.fr > >> > 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@Informix.com) #include > > 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----- > >