[PHP] Make install dumps core with PHP 5.2.0

2006-11-03 Thread Mendonce, Kiran (STSD)
On HP-UX Itanium, make install of PHP 5.2.0 dumps core while installing
pear. The php cli gets built fine, but when it is executed with the
install-pear-nozlib.phar as argumnt (part of the installation), it fails
with a SIGSEGV.

I noticed that someone has already filed a bug against this (#39252).
The trace is as follows :
HP gdb 5.2.03 for HP Itanium (32 or 64 bit) and target HP-UX 11.2x.
Copyright 1986 - 2001 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 5.2.03 (based on GDB) is covered by the
GNU General Public License. Type "show copying" to see the conditions to
change it and/or distribute copies. Type "show warranty" for
warranty/support.
..
Core was generated by `php'.
Program terminated with signal 11, Segmentation fault.
SEGV_MAPERR - Address not mapped to object
#0  0x403d7470:1 in zend_do_fcall_common_helper_SPEC ()
at /user/kiranm/php-5.2.0/Zend/zend_vm_execute.h:150
150 EX_T(opline->result.u.var).var.ptr_ptr =
&EX_T(opline->result.u.var).var.ptr;
(gdb) bt
#0  0x403d7470:1 in zend_do_fcall_common_helper_SPEC ()
at /user/kiranm/php-5.2.0/Zend/zend_vm_execute.h:150
#1  0x403d70c0:0 in ZEND_DO_FCALL_SPEC_CONST_HANDLER ()
at /user/kiranm/php-5.2.0/Zend/zend_vm_execute.h:1681
#2  0x404974a0:0 in execute ()
at /user/kiranm/php-5.2.0/Zend/zend_vm_execute.h:92
#3  0x403d7ec0:0 in zend_do_fcall_common_helper_SPEC ()
at /user/kiranm/php-5.2.0/Zend/zend_vm_execute.h:234
#4  0x403db060:0 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER ()
at /user/kiranm/php-5.2.0/Zend/zend_vm_execute.h:322
#5  0x404974a0:0 in execute ()
at /user/kiranm/php-5.2.0/Zend/zend_vm_execute.h:92
#6  0x409525b0:0 in zend_execute_scripts ()
at /user/kiranm/php-5.2.0/Zend/zend.c:1096
#7  0x40951b20:0 in php_execute_script ()
at /user/kiranm/php-5.2.0/main/main.c:1756
#8  0x4019d4c0:0 in main ()
at /user/kiranm/php-5.2.0/sapi/cli/php_cli.c:1027


Any idea how this can be resolved ?

Thanks and Regards,
Kiran

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



RE: [PHP] Re: Understanding persistent connections with oci8

2006-10-09 Thread Mendonce, Kiran (STSD)
I did some checking on the web and noticed that another user encountered
a similar problem and even reported it as a bug (#36634). The
documentation is misleading here with the intent of the
persistent_timeout setting not clearly explained.

If the behavior is as designed, can someone please update the
documentation so its more clearer to the end user ?

Thanks and Regards,
Kiran 

-Original Message-
From: Mendonce, Kiran (STSD) 
Sent: Wednesday, October 04, 2006 10:34 AM
To: php-general@lists.php.net
Subject: RE: [PHP] Re: Understanding persistent connections with oci8

I understand the performance boost one can get by reusing existing
connections. And I did see for myself that with the default settings,
oci_pconnect() does reuse all the connections.

But what should happen if there are idle connections and the timeout is
reached ? That is my question. What is the purpose of the
persistent_timeout setting ? Does it give the user a means of specifying
a timeout after which idle connections are removed ?

-Original Message-
From: Manuel Lemos [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 04, 2006 12:16 AM
To: php-general@lists.php.net
Subject: [PHP] Re: Understanding persistent connections with oci8

Hello,

on 10/03/2006 07:03 PM Mendonce, Kiran (STSD) said the following:
> This is a follow up to the bug (#39029) that I reported earlier which 
> has been repeatedly closed as bogus.
> 
> The oci8.persistent_timeout setting in the php.ini file is documented 
> as
> :
> "The maximum length of time (in seconds) that a given process is 
> allowed to maintain an idle persistent connection. Setting this option

> to -1 means that idle persistent connections will be maintained
forever. "
> 
> If I do not want the connection to be persist forever, then by using 
> this setting, I should be able to ensure that a connection is not idle

> for longer than what I specified. However, when I set 
> persistent_timeout to 10 seconds, I find that the connection is not 
> terminated even after 10 seconds have passed. In fact, it doesn't 
> terminate at all. So the question is what is the purpose of this 
> setting ? And what does an 'idle connection' mean ? A google query for

> 'idle timeout' yields enough results to point that when the timeout 
> occurs, the idle connection is terminated.
> 
> Obviously there is a bug somewhere. Either in the documentation or in 
> the behavior. Please advise.

I think that there is no bug and that option is useless.

If you are using Apache, it will rotate the processes that serve each
request. So, unless your server is mostly idle or your scripts rarely
access the database, your connections will keep being reused before
reaching that timeout.

If you are willing to reduce the number of persistent Oracle
connections, you will most likely get better results if you move your
site images to a separate Web server. Image requests do not establish
Oracle connections, but they raise the need for Apache to fork more
processes, which leads to more opened persistent connections.

Here you may find more details about that strategy:

http://www.meta-language.net/metabase-faq.html#excessive-connections

-- 

Regards,
Manuel Lemos

Metastorage - Data object relational mapping layer generator
http://www.metastorage.net/

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

--
PHP General Mailing List (http://www.php.net/) To unsubscribe, visit:
http://www.php.net/unsub.php

--
PHP General Mailing List (http://www.php.net/) To unsubscribe, visit:
http://www.php.net/unsub.php

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



RE: [PHP] Re: Understanding persistent connections with oci8

2006-10-04 Thread Mendonce, Kiran (STSD)
I understand the performance boost one can get by reusing existing
connections. And I did see for myself that with the default settings,
oci_pconnect() does reuse all the connections.

But what should happen if there are idle connections and the timeout is
reached ? That is my question. What is the purpose of the
persistent_timeout setting ? Does it give the user a means of specifying
a timeout after which idle connections are removed ?

-Original Message-
From: Manuel Lemos [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, October 04, 2006 12:16 AM
To: php-general@lists.php.net
Subject: [PHP] Re: Understanding persistent connections with oci8

Hello,

on 10/03/2006 07:03 PM Mendonce, Kiran (STSD) said the following:
> This is a follow up to the bug (#39029) that I reported earlier which 
> has been repeatedly closed as bogus.
> 
> The oci8.persistent_timeout setting in the php.ini file is documented 
> as
> :
> "The maximum length of time (in seconds) that a given process is 
> allowed to maintain an idle persistent connection. Setting this option

> to -1 means that idle persistent connections will be maintained
forever. "
> 
> If I do not want the connection to be persist forever, then by using 
> this setting, I should be able to ensure that a connection is not idle

> for longer than what I specified. However, when I set 
> persistent_timeout to 10 seconds, I find that the connection is not 
> terminated even after 10 seconds have passed. In fact, it doesn't 
> terminate at all. So the question is what is the purpose of this 
> setting ? And what does an 'idle connection' mean ? A google query for

> 'idle timeout' yields enough results to point that when the timeout 
> occurs, the idle connection is terminated.
> 
> Obviously there is a bug somewhere. Either in the documentation or in 
> the behavior. Please advise.

I think that there is no bug and that option is useless.

If you are using Apache, it will rotate the processes that serve each
request. So, unless your server is mostly idle or your scripts rarely
access the database, your connections will keep being reused before
reaching that timeout.

If you are willing to reduce the number of persistent Oracle
connections, you will most likely get better results if you move your
site images to a separate Web server. Image requests do not establish
Oracle connections, but they raise the need for Apache to fork more
processes, which leads to more opened persistent connections.

Here you may find more details about that strategy:

http://www.meta-language.net/metabase-faq.html#excessive-connections

-- 

Regards,
Manuel Lemos

Metastorage - Data object relational mapping layer generator
http://www.metastorage.net/

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

--
PHP General Mailing List (http://www.php.net/) To unsubscribe, visit:
http://www.php.net/unsub.php

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP] Understanding persistent connections with oci8

2006-10-03 Thread Mendonce, Kiran (STSD)
This is a follow up to the bug (#39029) that I reported earlier which
has been repeatedly closed as bogus.

The oci8.persistent_timeout setting in the php.ini file is documented as
:
"The maximum length of time (in seconds) that a given process is allowed
to maintain an idle persistent connection. Setting this option to -1
means that idle persistent connections will be maintained forever. "

If I do not want the connection to be persist forever, then by using
this setting, I should be able to ensure that a connection is not idle
for longer than what I specified. However, when I set persistent_timeout
to 10 seconds, I find that the connection is not terminated even after
10 seconds have passed. In fact, it doesn't terminate at all. So the
question is what is the purpose of this setting ? And what does an 'idle
connection' mean ? A google query for 'idle timeout' yields enough
results to point that when the timeout occurs, the idle connection is
terminated.

Obviously there is a bug somewhere. Either in the documentation or in
the behavior. Please advise.

Thanks and Regards,
Kiran

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php