Reply-To: "Jonathan Leffler" <Jonathan.Leffler@informix.com>
From: "Jonathan Leffler" <jleffler@informix.com>
To: <afalout@ihug.co.nz>
Subject: Re: FW: [PHP-DEV] Bug #4468: random ifx_pconnect code -439 withifx_connect
Date: Fri, 2 Jun 2000 07:04:03 +1300
Message-ID: <Pine.GSO.4.21.0006011059490.1170-100000@anubis>
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 IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <009101bfc6eb$4d4cb470$0101a8c0@csi.co.nz>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
X-Sender: jleffler@anubis

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@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" <afalout@xtra.co.nz>
>To: <pgrenier@framfab.fr>; <php-dev@lists.php.net>
>Cc: <Danny.Heijl@cevi.be>
>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@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'.
>> >
>> >
>> > --
>> > PHP Development Mailing List <http://www.php.net/>
>> > To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net
>> > For additional commands, e-mail: php-dev-help@lists.php.net
>> > To contact the list administrators, e-mail:
>> php-list-admin@lists.php.net
>> >
>> >
>> -----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@lists.php.net
>For additional commands, e-mail: php-dev-help@lists.php.net
>To contact the list administrators, e-mail:
>php-list-admin@lists.php.net
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: PGPfreeware 6.0.2i
>
>iQA/AwUBOS2J1BZH34ibpTRkEQLJtgCeNvYEo1jcJW2e49x0d2KO16UGJnEAoPVj
>9wlSk2OV2hNAZaOmxH2mg3pn
>=1q92
>-----END PGP SIGNATURE-----
>

-- 
Yours,
Jonathan Leffler (Jonathan.Leffler@Informix.com) #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!"


