#14254 [Com]: SQLERROR -439

[shai at shai dot org]

ID: 14254
Comment by: shai at shai dot org
Reported By: cedric dot boudin at iconmedialab dot com
Status: Closed
Bug Type: Informix related
Operating System: Solaris 8
PHP Version: 4.0.6
New Comment:

I am using AIX4.3.3
Apache 1.3.22
PHP 4.3.1
Infrmx 7.3.1
Same problem, I am using the RS6000-M80 and I can reproduce the
problem
when I am the only person on the machine with small queries. I suspect
that this maybe an apache related issue. I notices that my apache has
spawned off 20+ children. So I started messing with the persistant
connection and timeout options, seems to have made the problem go away
for now. Even with multiple hits, apache doesn't seems to be spawning
more than 12 helpers.

Any comments from anyone?


Previous Comments:
------------------------------------------------------------------------

[2003-06-09 14:59:52] klightse at water dot ca dot gov

We are seeing the same bug. We just discovered it, two days before we
go into production. Talk about a timing issue....

Solaris 8
Apache 1.3.26
PHP 4.3.0
Informix 9.3uc3

If anyone knows the solution, please post it. We are going to have to
reprogram this site in JSP if we can't fix it.

------------------------------------------------------------------------

[2003-04-25 12:44:15] jswinborne at nwc dot edu

I am also experiencing this error. It seems to come and go randomly.
We are using PHP 4.2.1 with Redhat 9.

------------------------------------------------------------------------

[2003-02-23 20:32:39] neil dot wilkinson at transport dot nsw dot gov
dot au

This problem still exists and does indeed occur most often when the
database is busy.

However, there will always be situations where the database is busy, so
increasing performance will only help in some situations.

The problem appears to be to do with how PHP responds to the callback
functions. I believe that the apache and native ESQL libraries are bug
free in this respect because embedded perl, etc (hitting the same
database from the same machine using the same ESQL libraries) never has
this problem.

Is there anyone out there that understands the PHP IFX source code and
could fix the callback functionality. Failing that I could have a go
if given some assistance.

FYI, the server specifics are:

Solaris 2.6
Apache 1.3.27
PHP 4.2.3
ESQL 7.24.UC6
Informix 7.30.UC8

Please do not close this bug unless the problem has been solved.
Several instances around this bug have been closed by the solution
"upgrade hardware" where there is clearly still an error to be fixed.

Regards,


Neil Wilkinson
--

------------------------------------------------------------------------

[2002-07-06 17:35:16] pschmidt at naxs dot net

Well, I see this problem every time I run my scripts. We are running:

PHP 4.2.1
Apache 1.3.24
ESQL/C Version 9.51

Some of the Informix tables are large.

Since I am seeing this consistently, I would really like to see a fix
to this problem. My scripts are somewhat complicated. But I can
reproduce the problem with a simple script. It contains:

-----------------------------------------------------------
<?php

// create connection
$connection = ifx_connect("<deleted>", "<deleted>", "<deleted")
or die("Couldn't create connection.");


// create SQL statement
$sql = "SELECT f1, f2, f3, f4, f5, f6, f7, f8, f9, f10, f11, f12, f13,
f14 FROM T1 where f1 < 500";

// execute SQL query and get result
$sql_result = ifx_query($sql,$connection)
or die("Couldn't execute query");

// format result in HTML table
ifx_htmltbl_result($sql_result,"border=1");

// free resources and close connection
ifx_free_result($sql_result);
ifx_close($connection);

?>
-----------------------------------------------------------

To reproduce this, I hit the refresh button on the browser before the
page had downloaded.

I tried switching it to pconnect and still got SQLCODE=-439 failures.
Although the table is big, I think the load was light (I tried this on
a Saturday afternoon.)

Anyone that has questions, feel free to send them to me at
[email]pschmidt@naxs.net[/email]

Best Regards,
Paul Schmidt
Action Web Creations

------------------------------------------------------------------------

[2002-05-25 13:15:11] [email]markonen@php.net[/email]

Your problem seems to be a pure performance issue.
Unfortunately these kinds of problems present themselves in
a non-deterministic fashion, which makes the symptoms hard
or impossible to debug. The cure, however, seems clear:
upgrade to PHP 4.2, upgrade the hardware, install Zend
Optimizer, buy Zend Cache -- anything to match your server
resources with the increased load on your system.

Based on your description of the scripts used, PHP 4 alone
should bring a huge performance increase. Your client's
possible unwillingness to pay for upgrades is quite simply
*their problem*. Hang in there, iconites ;-)



------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
[url]http://bugs.php.net/14254[/url]

--
Edit this bug report at [url]http://bugs.php.net/?id=14254&edit=1[/url]

[shai dot silberman at wsgriffith dot com]

ID: 14254
Comment by: shai dot silberman at wsgriffith dot com
Reported By: cedric dot boudin at iconmedialab dot com
Status: Closed
Bug Type: Informix related
Operating System: Solaris 8
PHP Version: 4.0.6
New Comment:

I was able to resolve this problem by installing a newer informix
client and recompiling PHP. I have not had a single 439 error since.


Previous Comments:
------------------------------------------------------------------------

[2003-08-08 13:55:07] klightse at water dot ca dot gov

Well, we came up with a hack to work around this miserable bug. You
can see our environment listed in the posting we made above. The
following is our assessment of the problem and the work around
solution:
--------------------------------------------------------

ifx_connect call (from Informix CSDK) fails on repeated queries. The
problem seems to be that it believes that the returned connection ID is
already in use!

The informix error 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.

Found reports of a PHP bug that seems related (#14254).
Bug goes back years, no fix reported. Just "make system faster".

I found anohter related(?) bug (#18534 ifx_close() leaves open
session)

Docs on ifx_connect show the following:

"In case a second call is made to ifx_connect() with the same
arguments, no new link will be established, but instead, the link
identifier of the already opened link will be returned."

Theory is that ifx_close doesn't immediately close the connection.
Since the parameters in ifx_connect are always the same (user, passwd
and database), the next ifx_connect() tries to use the existing
connection, and sometimes fails (busy, in process of closing, ???)

Our fix: Try using "rotating users" - we set up 10 "bdtdb" users
(bdtdb0-9), all with same uid/passwd on Solaris system. Use different
one for each connect, the chance of colliding with an open/bad
connections drops a lot (doesn't go awasy completely).

Here's our code:


// This is a hack to work around
// the bug 439 (see Informix docs

// - finderr 439) that relates to
// PHP concurrency problems with
// Informix.
// In essence, we are recycling
// usernames so that we can convince
// Informix to issue a new resource id
// for our connection, thus preventing
// collisions. Note that collisions
// could still occur, but it would be
// much less likely. To make it even
// less likely, use more user names.
// This is the best we can do,
// since no one here has the
// time to debug the PHP/Informix modules.

function getDBUserName() {

global $HTTP_SESSION_VARS;
$NUM_USERS = 9;

$user_index = $HTTP_SESSION_VARS['user_index'];


// First time in
if (!$user_index && $user_index != 0) {

// $user_index = rand (0,$NUM_USERS);
// Random # between 0 and numusers
// This doesn't work even if it is
// seeded. Always starts on
// same number. Go figure.

$user_index = 0;
}
else {

$user_index = $user_index + 1;

if ($user_index > $NUM_USERS) $user_index = 0;

}//else

$HTTP_SESSION_VARS['user_index'] = $user_index;

return ("bdtdb" . $user_index);

}//getDBUserName()



//----------------------- Defined Vars -------------

$db_userid = getDBUserName();
$db_password = "fish911";
$db_database = "www_bdat@ius_baydelta_tcp";


// ---- Then use these in your connection to db.
// We are definitely not using persistent
// connections.



Tested this hard - could not make it break, even with heavy load.
Prior to fix, even light loads would create error.

------------------------------------------------------------------------

[2003-07-10 20:04:59] shai at shai dot org

I am using AIX4.3.3
Apache 1.3.22
PHP 4.3.1
Infrmx 7.3.1
Same problem, I am using the RS6000-M80 and I can reproduce the
problem
when I am the only person on the machine with small queries. I suspect
that this maybe an apache related issue. I notices that my apache has
spawned off 20+ children. So I started messing with the persistant
connection and timeout options, seems to have made the problem go away
for now. Even with multiple hits, apache doesn't seems to be spawning
more than 12 helpers.

Any comments from anyone?

------------------------------------------------------------------------

[2003-06-09 14:59:52] klightse at water dot ca dot gov

We are seeing the same bug. We just discovered it, two days before we
go into production. Talk about a timing issue....

Solaris 8
Apache 1.3.26
PHP 4.3.0
Informix 9.3uc3

If anyone knows the solution, please post it. We are going to have to
reprogram this site in JSP if we can't fix it.

------------------------------------------------------------------------

[2003-04-25 12:44:15] jswinborne at nwc dot edu

I am also experiencing this error. It seems to come and go randomly.
We are using PHP 4.2.1 with Redhat 9.

------------------------------------------------------------------------

[2003-02-23 20:32:39] neil dot wilkinson at transport dot nsw dot gov
dot au

This problem still exists and does indeed occur most often when the
database is busy.

However, there will always be situations where the database is busy, so
increasing performance will only help in some situations.

The problem appears to be to do with how PHP responds to the callback
functions. I believe that the apache and native ESQL libraries are bug
free in this respect because embedded perl, etc (hitting the same
database from the same machine using the same ESQL libraries) never has
this problem.

Is there anyone out there that understands the PHP IFX source code and
could fix the callback functionality. Failing that I could have a go
if given some assistance.

FYI, the server specifics are:

Solaris 2.6
Apache 1.3.27
PHP 4.2.3
ESQL 7.24.UC6
Informix 7.30.UC8

Please do not close this bug unless the problem has been solved.
Several instances around this bug have been closed by the solution
"upgrade hardware" where there is clearly still an error to be fixed.

Regards,


Neil Wilkinson
--

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
[url]http://bugs.php.net/14254[/url]

--
Edit this bug report at [url]http://bugs.php.net/?id=14254&edit=1[/url]