Re: [PHP-DEV] [PATCH] fpm/typo: change some log about dynamic + homogenize log message about pool
On 12/14/2009 10:16 PM, Jérôme Loyet wrote: Hi tony, There is several things in this patch: 1- makes log message about pool concistent. I set it to [pool %s] message. Before there where different variants: pool %s, foo (pool %s) bar [pool %s] [%s] 2- corrects some log messages which were not very meaningful for end users 3- Some log level have been switched from NOTICE to DEBUG, so that the log_file in normal operation would not be a nightmare to read (with a lot of anoying and useless messages for end users) Wouldn't it make more sense to make this configurable? And thus allow people to log how they prefer.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] fpm/typo: change some log about dynamic + homogenize log message about pool
On 15.12.2009 12:04, Jani Taskinen wrote: 3- Some log level have been switched from NOTICE to DEBUG, so that the log_file in normal operation would not be a nightmare to read (with a lot of anoying and useless messages for end users) Wouldn't it make more sense to make this configurable? And thus allow people to log how they prefer.. Surely log_level is configurable. Jerome just changed error level of some error messages to reduce the amount of notices in the log. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] fpm/typo: change some log about dynamic + homogenize log message about pool
On 12/15/2009 11:14 AM, Antony Dovgal wrote: On 15.12.2009 12:04, Jani Taskinen wrote: 3- Some log level have been switched from NOTICE to DEBUG, so that the log_file in normal operation would not be a nightmare to read (with a lot of anoying and useless messages for end users) Wouldn't it make more sense to make this configurable? And thus allow people to log how they prefer.. Surely log_level is configurable. Jerome just changed error level of some error messages to reduce the amount of notices in the log. I replied badly, I meant ALL the points in the mail. Configurable log entries, levels, etc. Not some static fprintf() stuff. :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] fpm/typo: change some log about dynamic + homogenize log message about pool
On 15.12.2009 12:30, Jani Taskinen wrote: Surely log_level is configurable. Jerome just changed error level of some error messages to reduce the amount of notices in the log. I replied badly, I meant ALL the points in the mail. Configurable log entries, levels, etc. Not some static fprintf() stuff. :) Well, now you've lost me completely. 1- makes log message about pool concistent. I set it to [pool %s] message. Before there where different variants: pool %s, foo (pool %s) bar [pool %s] [%s] 2- corrects some log messages which were not very meaningful for end users Configurable error messages, huh? 3- Some log level have been switched from NOTICE to DEBUG, so that the log_file in normal operation would not be a nightmare to read (with a lot of anoying and useless messages for end users) Configurable error level for certain error messages? -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] fpm/typo: change some log about dynamic + homogenize log message about pool
The only two things that would come up after reading Jani's email is: 1) Make the log string configurable, such as CustomLog in apache 2) Configure the log level threshold, though I think that should already be there in the first place. On 12/15/09, Antony Dovgal t...@daylessday.org wrote: On 15.12.2009 12:30, Jani Taskinen wrote: Surely log_level is configurable. Jerome just changed error level of some error messages to reduce the amount of notices in the log. I replied badly, I meant ALL the points in the mail. Configurable log entries, levels, etc. Not some static fprintf() stuff. :) Well, now you've lost me completely. 1- makes log message about pool concistent. I set it to [pool %s] message. Before there where different variants: pool %s, foo (pool %s) bar [pool %s] [%s] 2- corrects some log messages which were not very meaningful for end users Configurable error messages, huh? 3- Some log level have been switched from NOTICE to DEBUG, so that the log_file in normal operation would not be a nightmare to read (with a lot of anoying and useless messages for end users) Configurable error level for certain error messages? -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- -- Tjerk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] fpm/typo: change some log about dynamic + homogenize log message about pool
2009/12/15 Tjerk Anne Meesters datib...@php.net: The only two things that would come up after reading Jani's email is: so am I 1) Make the log string configurable, such as CustomLog in apache Yes but CustomLog is for access log, this feature is not present in php-fpm (should it be ?) All the log message (my patch is changing) are error, debug or warning message like: - WARNING: unable to open log file - php-fpm started well - unable to fork ... There is no way to make this configurable ... because it's totally useless 2) Configure the log level threshold, though I think that should already be there in the first place. Yes it's already in place On 12/15/09, Antony Dovgal t...@daylessday.org wrote: On 15.12.2009 12:30, Jani Taskinen wrote: Surely log_level is configurable. Jerome just changed error level of some error messages to reduce the amount of notices in the log. I replied badly, I meant ALL the points in the mail. Configurable log entries, levels, etc. Not some static fprintf() stuff. :) Well, now you've lost me completely. 1- makes log message about pool concistent. I set it to [pool %s] message. Before there where different variants: pool %s, foo (pool %s) bar [pool %s] [%s] 2- corrects some log messages which were not very meaningful for end users Configurable error messages, huh? 3- Some log level have been switched from NOTICE to DEBUG, so that the log_file in normal operation would not be a nightmare to read (with a lot of anoying and useless messages for end users) Configurable error level for certain error messages? -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- -- Tjerk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] fpm/typo: change some log about dynamic + homogenize log message about pool
On 15.12.2009 15:19, Tjerk Anne Meesters wrote: The only two things that would come up after reading Jani's email is: 1) Make the log string configurable, such as CustomLog in apache CustomLog is needed in Apache because there are so much variables available. Here we have time, pid, function and line. With log_level=debug all of them are printed, in other cases only time gets into the log, which makes perfect sense to me. 2) Configure the log level threshold, though I think that should already be there in the first place. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [BUG] fpm : bugs with epoll
Hi I just figured out a bug with epoll on the last php-fpm version from svn. It seems that with epoll only (no problem with poll or select -- don't have a freebsd ready to check kqueue), the catch_worker_output is buggy. With catch_workers_output set to no, all output to stdout or stderr from children are sent to /dev/null. With catch_workers_output set to yes, output to stdout or stderr from children are sent through 2 pipes to the parent process. The parent process has an event on reading on those pipes. When a child write to one of the pipes, the parent write to the log_file something like: Dec 15 16:48:10.670668 [WARNING] child 24035 (pool default) said into stderr: Connection from disallowed IP address '127.0.0.1' is dropped. To check it in action, simply change the allowed_clients to something else than 127.0.0.1 (value name=allowed_clients127.0.0.2/value). Restart php-fpm and try connect to php-fpm (with telnet 127.0.0.1 9000 or through a webserver in front). You should see the previous log in your error_log each time you try to connect to fpm, it should be written in (pseudo) realtime. Here is a normal error_log in this situation with 2 children: # EVENT_NOEPOLL= ./sapi/fpm/php-fpm Dec 15 16:58:45.931952 [NOTICE] getrlimit(nofile): max:1024, cur:1024 Dec 15 16:58:45.932489 [NOTICE] libevent: using poll Dec 15 16:58:45.932797 [NOTICE] fpm is running, pid 24200 Dec 15 16:58:45.934172 [NOTICE] child 24201 (pool default) started Dec 15 16:58:45.935521 [NOTICE] child 24202 (pool default) started Dec 15 16:58:45.935782 [NOTICE] libevent: entering main loop Dec 15 16:58:50.667584 [WARNING] child 24201 (pool default) said into stderr: Connection from disallowed IP address '127.0.0.1' is dropped. Dec 15 16:58:51.610799 [WARNING] child 24202 (pool default) said into stderr: Connection from disallowed IP address '127.0.0.1' is dropped. Dec 15 16:58:54.231871 [WARNING] child 24201 (pool default) said into stderr: Connection from disallowed IP address '127.0.0.1' is dropped. Dec 15 16:58:54.432654 [WARNING] child 24202 (pool default) said into stderr: Connection from disallowed IP address '127.0.0.1' is dropped. ^CDec 15 16:58:56.836278 [NOTICE] received SIGINT Dec 15 16:58:56.836324 [NOTICE] switching to 'terminating' state Dec 15 16:58:56.836342 [NOTICE] sending signal 15 SIGTERM to child 24202 (pool default) Dec 15 16:58:56.836355 [NOTICE] sending signal 15 SIGTERM to child 24201 (pool default) Dec 15 16:58:56.836363 [NOTICE] 2 children are still alive Dec 15 16:58:56.836822 [NOTICE] received SIGCHLD Dec 15 16:58:56.836901 [WARNING] child 24202 (pool default) exited on signal 2 SIGINT after 10.901391 seconds from start Dec 15 16:58:56.837290 [NOTICE] received SIGCHLD Dec 15 16:58:56.837342 [WARNING] child 24201 (pool default) exited on signal 2 SIGINT after 10.903209 seconds from start Dec 15 16:58:56.837357 [NOTICE] exiting, bye-bye! I made 4 connections and in real time I have in the error_log the corresponding error messages. Note that I'm using POLL here. We can see that child 24201 handled the 1st and 3rd connection and the child 24202 handled the 2nd and 4th connection. Now with EPOLL: # ./sapi/fpm/php-fpm Dec 15 17:01:34.721411 [NOTICE] getrlimit(nofile): max:1024, cur:1024 Dec 15 17:01:34.721973 [NOTICE] libevent: using epoll Dec 15 17:01:34.722286 [NOTICE] fpm is running, pid 24375 Dec 15 17:01:34.723695 [NOTICE] child 24376 (pool default) started Dec 15 17:01:34.725099 [NOTICE] child 24377 (pool default) started Dec 15 17:01:34.725383 [NOTICE] libevent: entering main loop Dec 15 17:01:37.044002 [WARNING] child 24377 (pool default) said into stderr: Connection from disallowed IP address '127.0.0.1' is dropped. Dec 15 17:01:38.215927 [WARNING] child 24377 (pool default) said into stderr: Connection from disallowed IP address '127.0.0.1' is dropped. ^CDec 15 17:01:41.237395 [NOTICE] received SIGINT Dec 15 17:01:41.237443 [NOTICE] switching to 'terminating' state Dec 15 17:01:41.237462 [NOTICE] sending signal 15 SIGTERM to child 24377 (pool default) Dec 15 17:01:41.237473 [NOTICE] sending signal 15 SIGTERM to child 24376 (pool default) Dec 15 17:01:41.237481 [NOTICE] 2 children are still alive Dec 15 17:01:41.237938 [NOTICE] received SIGCHLD Dec 15 17:01:41.238015 [WARNING] child 24377 (pool default) exited on signal 2 SIGINT after 6.512935 seconds from start Dec 15 17:01:41.238389 [NOTICE] received SIGCHLD Dec 15 17:01:41.238441 [WARNING] child 24376 (pool default) exited on signal 2 SIGINT after 6.514792 seconds from start Dec 15 17:01:41.238473 [WARNING] child 24376 (pool default) said into stderr: Connection from disallowed IP address '127.0.0.1' is dropped. Dec 15 17:01:41.238490 [WARNING] child 24376 (pool default) said into stderr: Connection from disallowed IP address '127.0.0.1' is dropped., pipe is closed Dec 15 17:01:41.238502 [NOTICE] exiting, bye-bye! I made the same number of connection and only the ones handled by the last created child has been written on real time.
Re: [PHP-DEV] Closures and $this
Hello again, Discuss away! I'm a little disappointed by the non-outcome of this debate. Very few people have responded and most of them seem to agree proposal (A) should be implemented, perhaps with the additional bind/bindTo as in my proposal and perhaps not. The problem here is: (A) was exactly the thing that was implemented and that people started to have a problem with as soon as the first or second beta of PHP 5.3 was released. And because the feedback came in so late, Lukas Johannes decided to remove $this support from closures for PHP 5.3 in order to be able to decide that later on. So basically we're at the same point where we were a little more year ago: There's an RFC for this (the semantics of $this support were discussed in the original closures RFC!) and the people who read it on internals@ support it. However, I predict that if we implement exactly the semantics that the RFC proposes, we will get into the same discussion we had with PHP 5.3 just before the release of PHP 6... (or 5.4 should there be one). So: What now? Regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closures and $this
On 15.12.2009, at 20:01, Christian Seiler wrote: Hello again, Discuss away! I'm a little disappointed by the non-outcome of this debate. Very few people have responded and most of them seem to agree proposal (A) should be implemented, perhaps with the additional bind/bindTo as in my proposal and perhaps not. The problem here is: (A) was exactly the thing that was implemented and that people started to have a problem with as soon as the first or second beta of PHP 5.3 was released. And because the feedback came in so late, Lukas Johannes decided to remove $this support from closures for PHP 5.3 in order to be able to decide that later on. So basically we're at the same point where we were a little more year ago: There's an RFC for this (the semantics of $this support were discussed in the original closures RFC!) and the people who read it on internals@ support it. However, I predict that if we implement exactly the semantics that the RFC proposes, we will get into the same discussion we had with PHP 5.3 just before the release of PHP 6... (or 5.4 should there be one). So: What now? Call for a vote. This time around people cannot claim to not have had time to review the issue. Also back then we tried to play it safe because of the short time before we were to release. This time there is more time for this to mature if needed inside svn. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [BUG] fpm : bugs with epoll
Le 15 décembre 2009 17:08, Jérôme Loyet jer...@loyet.net a écrit : Hi I just figured out a bug with epoll on the last php-fpm version from svn. It seems that with epoll only (no problem with poll or select -- don't have a freebsd ready to check kqueue), the catch_worker_output is buggy. I just tested on freebsd with libevent 1.4.12. When using kqueue the problems does not occur. It seems to be a an epoll problem.I'll check on another linux like fedora (I tested only on ubuntu) With catch_workers_output set to no, all output to stdout or stderr from children are sent to /dev/null. With catch_workers_output set to yes, output to stdout or stderr from children are sent through 2 pipes to the parent process. The parent process has an event on reading on those pipes. When a child write to one of the pipes, the parent write to the log_file something like: Dec 15 16:48:10.670668 [WARNING] child 24035 (pool default) said into stderr: Connection from disallowed IP address '127.0.0.1' is dropped. To check it in action, simply change the allowed_clients to something else than 127.0.0.1 (value name=allowed_clients127.0.0.2/value). Restart php-fpm and try connect to php-fpm (with telnet 127.0.0.1 9000 or through a webserver in front). You should see the previous log in your error_log each time you try to connect to fpm, it should be written in (pseudo) realtime. Here is a normal error_log in this situation with 2 children: # EVENT_NOEPOLL= ./sapi/fpm/php-fpm Dec 15 16:58:45.931952 [NOTICE] getrlimit(nofile): max:1024, cur:1024 Dec 15 16:58:45.932489 [NOTICE] libevent: using poll Dec 15 16:58:45.932797 [NOTICE] fpm is running, pid 24200 Dec 15 16:58:45.934172 [NOTICE] child 24201 (pool default) started Dec 15 16:58:45.935521 [NOTICE] child 24202 (pool default) started Dec 15 16:58:45.935782 [NOTICE] libevent: entering main loop Dec 15 16:58:50.667584 [WARNING] child 24201 (pool default) said into stderr: Connection from disallowed IP address '127.0.0.1' is dropped. Dec 15 16:58:51.610799 [WARNING] child 24202 (pool default) said into stderr: Connection from disallowed IP address '127.0.0.1' is dropped. Dec 15 16:58:54.231871 [WARNING] child 24201 (pool default) said into stderr: Connection from disallowed IP address '127.0.0.1' is dropped. Dec 15 16:58:54.432654 [WARNING] child 24202 (pool default) said into stderr: Connection from disallowed IP address '127.0.0.1' is dropped. ^CDec 15 16:58:56.836278 [NOTICE] received SIGINT Dec 15 16:58:56.836324 [NOTICE] switching to 'terminating' state Dec 15 16:58:56.836342 [NOTICE] sending signal 15 SIGTERM to child 24202 (pool default) Dec 15 16:58:56.836355 [NOTICE] sending signal 15 SIGTERM to child 24201 (pool default) Dec 15 16:58:56.836363 [NOTICE] 2 children are still alive Dec 15 16:58:56.836822 [NOTICE] received SIGCHLD Dec 15 16:58:56.836901 [WARNING] child 24202 (pool default) exited on signal 2 SIGINT after 10.901391 seconds from start Dec 15 16:58:56.837290 [NOTICE] received SIGCHLD Dec 15 16:58:56.837342 [WARNING] child 24201 (pool default) exited on signal 2 SIGINT after 10.903209 seconds from start Dec 15 16:58:56.837357 [NOTICE] exiting, bye-bye! I made 4 connections and in real time I have in the error_log the corresponding error messages. Note that I'm using POLL here. We can see that child 24201 handled the 1st and 3rd connection and the child 24202 handled the 2nd and 4th connection. Now with EPOLL: # ./sapi/fpm/php-fpm Dec 15 17:01:34.721411 [NOTICE] getrlimit(nofile): max:1024, cur:1024 Dec 15 17:01:34.721973 [NOTICE] libevent: using epoll Dec 15 17:01:34.722286 [NOTICE] fpm is running, pid 24375 Dec 15 17:01:34.723695 [NOTICE] child 24376 (pool default) started Dec 15 17:01:34.725099 [NOTICE] child 24377 (pool default) started Dec 15 17:01:34.725383 [NOTICE] libevent: entering main loop Dec 15 17:01:37.044002 [WARNING] child 24377 (pool default) said into stderr: Connection from disallowed IP address '127.0.0.1' is dropped. Dec 15 17:01:38.215927 [WARNING] child 24377 (pool default) said into stderr: Connection from disallowed IP address '127.0.0.1' is dropped. ^CDec 15 17:01:41.237395 [NOTICE] received SIGINT Dec 15 17:01:41.237443 [NOTICE] switching to 'terminating' state Dec 15 17:01:41.237462 [NOTICE] sending signal 15 SIGTERM to child 24377 (pool default) Dec 15 17:01:41.237473 [NOTICE] sending signal 15 SIGTERM to child 24376 (pool default) Dec 15 17:01:41.237481 [NOTICE] 2 children are still alive Dec 15 17:01:41.237938 [NOTICE] received SIGCHLD Dec 15 17:01:41.238015 [WARNING] child 24377 (pool default) exited on signal 2 SIGINT after 6.512935 seconds from start Dec 15 17:01:41.238389 [NOTICE] received SIGCHLD Dec 15 17:01:41.238441 [WARNING] child 24376 (pool default) exited on signal 2 SIGINT after 6.514792 seconds from start Dec 15 17:01:41.238473 [WARNING] child 24376 (pool default) said into stderr: Connection from disallowed IP address
[PHP-DEV] Closures and $this: Please vote!
Hi Lukas, Call for a vote. This time around people cannot claim to not have had time to review the issue. Also back then we tried to play it safe because of the short time before we were to release. This time there is more time for this to mature if needed inside svn. Ok, so then I call for a vote. Again, here are the options: (0): No $this in closures, keep it that way. (keep PHP 5.3 behavior) (A): Original closures implementation: $this is always the object context at closure creation. No possibility to do $someObject-closureProperty(...) and thus no possibility to extend objects! (C): Javascript-like behaviour: Bind $this only when calling the closure as object method, else $this is undefined. (D): JS-like behaviour on top of (A). Please look at the RFC as to why I consider it to be a *REALLY*, *REALLY* bad idea. (A+): (A) + Closure::bind Closure-bindTo for rebinding if this is wanted the possibility to call a closure as an object method. (See last section of RFC for details) My vote: (A+) Regards, Christian PS: Note that I removed (B) from the possible options since I believe it to be an EXTREMELY bad idea if one thinks it through. It was only added to the RFC in order to give an overview over what was discussed previously. Unless someone can make an extremely compelling case why I'm wrong in this respect, I will refuse to implement (B). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [BUG] fpm : bugs with epoll
I found a solution:
Just after the fork() call to create a child, the first thing to do is
to call event_init() to create a fresh libevent environment for the
new child. In fact epoll shares the same fd between process and having
not libevent reinit make things not working as excepted. It's not the
case for others event libraries.
There is no need to make this for the main fork because the event_init
is called after this fork.
So here is the patch. As it's very simple I put it here and not as an
attached file
++ Jerome
Index: sapi/fpm/fpm/fpm_children.c
===
--- sapi/fpm/fpm/fpm_children.c (révision 292175)
+++ sapi/fpm/fpm/fpm_children.c (copie de travail)
@@ -373,6 +373,7 @@
switch (pid) {
case 0 :
+ event_init();
fpm_child_resources_use(child);
fpm_globals.is_child = 1;
if (in_event_loop) {
Le 15 décembre 2009 20:25, Jérôme Loyet jer...@loyet.net a écrit :
Le 15 décembre 2009 17:08, Jérôme Loyet jer...@loyet.net a écrit :
Hi
I just figured out a bug with epoll on the last php-fpm version from svn.
It seems that with epoll only (no problem with poll or select -- don't
have a freebsd ready to check kqueue), the catch_worker_output is
buggy.
I just tested on freebsd with libevent 1.4.12. When using kqueue the
problems does not occur. It seems to be a an epoll problem.I'll check
on another linux like fedora (I tested only on ubuntu)
With catch_workers_output set to no, all output to stdout or stderr
from children are sent to /dev/null.
With catch_workers_output set to yes, output to stdout or stderr
from children are sent through 2 pipes to the parent process. The
parent process has an event on reading on those pipes. When a child
write to one of the pipes, the parent write to the log_file something
like:
Dec 15 16:48:10.670668 [WARNING] child 24035 (pool default) said into
stderr: Connection from disallowed IP address '127.0.0.1' is
dropped.
To check it in action, simply change the allowed_clients to something
else than 127.0.0.1 (value name=allowed_clients127.0.0.2/value).
Restart php-fpm and try connect to php-fpm (with telnet 127.0.0.1
9000 or through a webserver in front). You should see the previous
log in your error_log each time you try to connect to fpm, it should
be written in (pseudo) realtime.
Here is a normal error_log in this situation with 2 children:
# EVENT_NOEPOLL= ./sapi/fpm/php-fpm
Dec 15 16:58:45.931952 [NOTICE] getrlimit(nofile): max:1024, cur:1024
Dec 15 16:58:45.932489 [NOTICE] libevent: using poll
Dec 15 16:58:45.932797 [NOTICE] fpm is running, pid 24200
Dec 15 16:58:45.934172 [NOTICE] child 24201 (pool default) started
Dec 15 16:58:45.935521 [NOTICE] child 24202 (pool default) started
Dec 15 16:58:45.935782 [NOTICE] libevent: entering main loop
Dec 15 16:58:50.667584 [WARNING] child 24201 (pool default) said into
stderr: Connection from disallowed IP address '127.0.0.1' is
dropped.
Dec 15 16:58:51.610799 [WARNING] child 24202 (pool default) said into
stderr: Connection from disallowed IP address '127.0.0.1' is
dropped.
Dec 15 16:58:54.231871 [WARNING] child 24201 (pool default) said into
stderr: Connection from disallowed IP address '127.0.0.1' is
dropped.
Dec 15 16:58:54.432654 [WARNING] child 24202 (pool default) said into
stderr: Connection from disallowed IP address '127.0.0.1' is
dropped.
^CDec 15 16:58:56.836278 [NOTICE] received SIGINT
Dec 15 16:58:56.836324 [NOTICE] switching to 'terminating' state
Dec 15 16:58:56.836342 [NOTICE] sending signal 15 SIGTERM to child
24202 (pool default)
Dec 15 16:58:56.836355 [NOTICE] sending signal 15 SIGTERM to child
24201 (pool default)
Dec 15 16:58:56.836363 [NOTICE] 2 children are still alive
Dec 15 16:58:56.836822 [NOTICE] received SIGCHLD
Dec 15 16:58:56.836901 [WARNING] child 24202 (pool default) exited on
signal 2 SIGINT after 10.901391 seconds from start
Dec 15 16:58:56.837290 [NOTICE] received SIGCHLD
Dec 15 16:58:56.837342 [WARNING] child 24201 (pool default) exited on
signal 2 SIGINT after 10.903209 seconds from start
Dec 15 16:58:56.837357 [NOTICE] exiting, bye-bye!
I made 4 connections and in real time I have in the error_log the
corresponding error messages. Note that I'm using POLL here. We can
see that child 24201 handled the 1st and 3rd connection and the child
24202 handled the 2nd and 4th connection.
Now with EPOLL:
# ./sapi/fpm/php-fpm
Dec 15 17:01:34.721411 [NOTICE] getrlimit(nofile): max:1024, cur:1024
Dec 15 17:01:34.721973 [NOTICE] libevent: using epoll
Dec 15 17:01:34.722286 [NOTICE] fpm is running, pid 24375
Dec 15 17:01:34.723695 [NOTICE] child 24376 (pool default) started
Dec 15 17:01:34.725099 [NOTICE] child 24377 (pool default) started
Dec 15 17:01:34.725383 [NOTICE] libevent: entering main loop
Re: [PHP-DEV] Closures and $this: Please vote!
On Tue, Dec 15, 2009 at 20:46, Christian Seiler chris...@gmx.net wrote: (A): Original closures implementation: $this is always the object context at closure creation. No possibility to do $someObject-closureProperty(...) and thus no possibility to extend objects! +1 Preferably without any Closure-bindto black arts. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closures and $this: Please vote!
Hi!
Ok, so then I call for a vote. Again, here are the options:
A+, no direct method calling (get/call problem would be messy)
one additional thing:
$a = static function () {}
should leave $this not bound (in case for some reason you don't want it
to be bound, e.g. to avoid keeping reference to a large object)
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closures and $this: Please vote!
Hi, Ok, so then I call for a vote. Again, here are the options: A+, no direct method calling (get/call problem would be messy) I don't quite follow: Why A+ if no direct method calling? What would be the point of allowing bindTo() if $obj-closureProp() doesn't work anyway? If you don't want $obj-closureProp() I'd expect you to vote for A and not A+... (If you want to stick to that it's fine, I'm just a little stupefied.) Regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closures and $this: Please vote!
On 15.12.2009, at 22:46, Christian Seiler wrote: Ok, so then I call for a vote. Again, here are the options: (0): No $this in closures, keep it that way. (keep PHP 5.3 behavior) I vote for (0) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] fpm/typo: change some log about dynamic + homogenize log message about pool
On Tue, Dec 15, 2009 at 4:25 AM, Antony Dovgal t...@daylessday.org wrote: Here we have time, pid, function and line. With log_level=debug all of them are printed, in other cases only time gets into the log, which makes perfect sense to me. +1 to Antony and Jérôme. Having a log format parameter seems a bit overkill for debug/internal messages. Unless php-fpm's logfile turns into some kind of access log that winds up being parsed, I don't see the need. However if people have ideas on how this will help or be useful (i.e. you -are- planning on running logfiles or logwatch or something) then it might be smart to bring it back to the table again. Jérôme and I were talking about some way to grab statistics in real-time (as close as they can be, obviously the connection counts can change rapidly) and I thought it might make sense to have a PHP function which can access that information. Originally he had mentioned a /url-prefix but that seems a bit complex, having to configure it in the webserver and such. I'm thinking of something like APC's apc_cache_info() - returns a structured array of useful info. Then you could build anything you wish around it (although you would have to execute it through the FPM-enabled SAPI most likely) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closures and $this: Please vote!
A+, but I'm not an internal dev. On 12/15/2009 21:46, Christian Seiler wrote: Hi Lukas, Call for a vote. This time around people cannot claim to not have had time to review the issue. Also back then we tried to play it safe because of the short time before we were to release. This time there is more time for this to mature if needed inside svn. Ok, so then I call for a vote. Again, here are the options: (0): No $this in closures, keep it that way. (keep PHP 5.3 behavior) (A): Original closures implementation: $this is always the object context at closure creation. No possibility to do $someObject-closureProperty(...) and thus no possibility to extend objects! (C): Javascript-like behaviour: Bind $this only when calling the closure as object method, else $this is undefined. (D): JS-like behaviour on top of (A). Please look at the RFC as to why I consider it to be a *REALLY*, *REALLY* bad idea. (A+): (A) + Closure::bind Closure-bindTo for rebinding if this is wanted the possibility to call a closure as an object method. (See last section of RFC for details) My vote: (A+) Regards, Christian PS: Note that I removed (B) from the possible options since I believe it to be an EXTREMELY bad idea if one thinks it through. It was only added to the RFC in order to give an overview over what was discussed previously. Unless someone can make an extremely compelling case why I'm wrong in this respect, I will refuse to implement (B). -- Ionut G. Stan I'm under construction | http://blog.igstan.ro/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closures and $this: Please vote!
Hi,
Maybe I don't exactly understand the need for closureProperty(); also,
I haven't read the rfc ;-)
My understanding would be that you can treat it as a callable object, like so:
$a = function($msg) { echo $this-id, : , $msg, [ calls: ,
++$this-calls, ];
}
$a-id = 123;
$a(hello world);
If that can be done with A or A+ my vote goes for either one. I don't
think rebinding will be very useful or intuitive though (unless one
would want to use it as a drop-in method for their classes).
On 12/16/09, Ionut G. Stan ionut.g.s...@gmail.com wrote:
A+, but I'm not an internal dev.
On 12/15/2009 21:46, Christian Seiler wrote:
Hi Lukas,
Call for a vote. This time around people cannot claim to not have had
time to review the issue. Also back then we tried to play it safe
because of the short time before we were to release. This time there is
more time for this to mature if needed inside svn.
Ok, so then I call for a vote. Again, here are the options:
(0): No $this in closures, keep it that way. (keep PHP 5.3 behavior)
(A): Original closures implementation:
$this is always the object context at
closure creation. No possibility to do
$someObject-closureProperty(...) and thus
no possibility to extend objects!
(C): Javascript-like behaviour: Bind $this only when calling
the closure as object method, else $this is undefined.
(D): JS-like behaviour on top of (A).
Please look at the RFC as to why I consider it to be a
*REALLY*, *REALLY* bad idea.
(A+): (A) + Closure::bind Closure-bindTo for rebinding
if this is wanted the possibility to call a closure as an object
method. (See last section of RFC for details)
My vote: (A+)
Regards,
Christian
PS: Note that I removed (B) from the possible options since I believe it
to be an EXTREMELY bad idea if one thinks it through. It was only added
to the RFC in order to give an overview over what was discussed
previously. Unless someone can make an extremely compelling case why I'm
wrong in this respect, I will refuse to implement (B).
--
Ionut G. Stan
I'm under construction | http://blog.igstan.ro/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
--
Tjerk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closures and $this: Please vote!
2009/12/15 Ionut G. Stan ionut.g.s...@gmail.com: A+, but I'm not an internal dev. On 12/15/2009 21:46, Christian Seiler wrote: Hi Lukas, Call for a vote. This time around people cannot claim to not have had time to review the issue. Also back then we tried to play it safe because of the short time before we were to release. This time there is more time for this to mature if needed inside svn. Ok, so then I call for a vote. Again, here are the options: (0): No $this in closures, keep it that way. (keep PHP 5.3 behavior) (A): Original closures implementation: $this is always the object context at closure creation. No possibility to do $someObject-closureProperty(...) and thus no possibility to extend objects! (C): Javascript-like behaviour: Bind $this only when calling the closure as object method, else $this is undefined. (D): JS-like behaviour on top of (A). Please look at the RFC as to why I consider it to be a *REALLY*, *REALLY* bad idea. (A+): (A) + Closure::bind Closure-bindTo for rebinding if this is wanted the possibility to call a closure as an object method. (See last section of RFC for details) My vote: (A+) Regards, Christian PS: Note that I removed (B) from the possible options since I believe it to be an EXTREMELY bad idea if one thinks it through. It was only added to the RFC in order to give an overview over what was discussed previously. Unless someone can make an extremely compelling case why I'm wrong in this respect, I will refuse to implement (B). -- Ionut G. Stan I'm under construction | http://blog.igstan.ro/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php (A+) +1 from a non internals voter. -- - Richard Quadling Standing on the shoulders of some very clever giants! EE : http://www.experts-exchange.com/M_248814.html Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Closures and $this: Please vote!
Christian Seiler wrote Hi Lukas, Call for a vote. This time around people cannot claim to not have had time to review the issue. Also back then we tried to play it safe because of the short time before we were to release. This time there is more time for this to mature if needed inside svn. Ok, so then I call for a vote. Again, here are the options: (0): No $this in closures, keep it that way. (keep PHP 5.3 behavior) (A): Original closures implementation: $this is always the object context at closure creation. No possibility to do $someObject-closureProperty(...) and thus no possibility to extend objects! (C): Javascript-like behaviour: Bind $this only when calling the closure as object method, else $this is undefined. (D): JS-like behaviour on top of (A). Please look at the RFC as to why I consider it to be a *REALLY*, *REALLY* bad idea. (A+): (A) + Closure::bind Closure-bindTo for rebinding if this is wanted the possibility to call a closure as an object method. (See last section of RFC for details) My vote: (A+) Regards, Christian FWIW, another non-internal-dev vote for (A+). Best Regards Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closures and $this: Please vote!
On Tuesday 15 December 2009 1:46:44 pm Christian Seiler wrote: Hi Lukas, Call for a vote. This time around people cannot claim to not have had time to review the issue. Also back then we tried to play it safe because of the short time before we were to release. This time there is more time for this to mature if needed inside svn. Ok, so then I call for a vote. Again, here are the options: (0): No $this in closures, keep it that way. (keep PHP 5.3 behavior) (A): Original closures implementation: $this is always the object context at closure creation. No possibility to do $someObject-closureProperty(...) and thus no possibility to extend objects! (C): Javascript-like behaviour: Bind $this only when calling the closure as object method, else $this is undefined. (D): JS-like behaviour on top of (A). Please look at the RFC as to why I consider it to be a *REALLY*, *REALLY* bad idea. (A+): (A) + Closure::bind Closure-bindTo for rebinding if this is wanted the possibility to call a closure as an object method. (See last section of RFC for details) My vote: (A+) Another non-C-developing PHP coder voting for A+. I like the explicitness of knowing when $this is going to change on me, and it allows for dynamic extension. Regarding the other points noted in the RFC, I believe that when a closure is bound to an object it should have full access to private/protected properties of that object. (I believe that is option 2.) If that is not done, then being able to call $foo-aClosure() is really just syntactic sugar and not especially useful. When cloning an object with a bound closure, my expectation is that it would behave the same way as an object or resource that is a property of the cloned object. I don't know if that makes sense in the context of closures, but that is what my knee-jerk expectation would be. I am not sure we can rely on the __clone() method to handle rebinding the closure. The point of binding closures to an object is so that objects can get extra methods post-creation. How can the __clone() method, which is written pre-creation, know what closures have been bound to it in order to rebind them to the new object? If the developer knows the exact name in advance to rebind, then generally that code could just be a normal method. I don't see how one could logically rebind a closure on __clone(). -- Larry Garfield la...@garfieldtech.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] fpm/typo: change some log about dynamic + homogenize log message about pool
On Tue, Dec 15, 2009 at 02:27:30PM -0800, Michael Shadle wrote: However if people have ideas on how this will help or be useful (i.e. you -are- planning on running logfiles or logwatch or something) then it might be smart to bring it back to the table again. Jérôme and I were talking about some way to grab statistics in real-time (as close as they can be, obviously the connection counts can change rapidly) and I thought it might make sense to have a PHP function which can access that information. Originally he had mentioned a /url-prefix but that seems a bit complex, having to configure it in the webserver and such. I don't use FPM, but I certainly am a heavy user of PostgreSQL's 'log_line_prefix' configuration setting. For those who aren't familiar with it, check out the table at http://www.postgresql.org/docs/8.4/static/runtime-config-logging.html for some ideas on the kinds of information you can add (or exclude) from logfile lines. In production enviroments, I don't use many of these, as any analysis done on them will likely come hours (if not days) after the issue occurred; however, in a development or staging environment, knowing something like the PID can be very useful. It strikes me that these kind of rules might also apply in the FPM case - but, again, I'm not actually *using* FPM, so maybe I'm wrong. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] fpm/typo: change some log about dynamic + homogenize log message about pool
On Tue, Dec 15, 2009 at 9:59 PM, Joey Smith j...@joeysmith.com wrote: On Tue, Dec 15, 2009 at 02:27:30PM -0800, Michael Shadle wrote: However if people have ideas on how this will help or be useful (i.e. you -are- planning on running logfiles or logwatch or something) then it might be smart to bring it back to the table again. Jérôme and I were talking about some way to grab statistics in real-time (as close as they can be, obviously the connection counts can change rapidly) and I thought it might make sense to have a PHP function which can access that information. Originally he had mentioned a /url-prefix but that seems a bit complex, having to configure it in the webserver and such. I don't use FPM, but I certainly am a heavy user of PostgreSQL's 'log_line_prefix' configuration setting. For those who aren't familiar with it, check out the table at http://www.postgresql.org/docs/8.4/static/runtime-config-logging.html for some ideas on the kinds of information you can add (or exclude) from logfile lines. In production enviroments, I don't use many of these, as any analysis done on them will likely come hours (if not days) after the issue occurred; however, in a development or staging environment, knowing something like the PID can be very useful. It strikes me that these kind of rules might also apply in the FPM case - but, again, I'm not actually *using* FPM, so maybe I'm wrong. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I can see this sort of thing being incredibly useful. I *am* using FPM in production (dozens of sites, some share pools, some don't) and if that level of logging was supported, a lot of application-level logging that I'm doing would be rendered obsolete. It would be nice to have a more granular approach to logging what went wrong (knowing what worker, for instance, which I think is currently unavailable) and enough information to re-create the problem. Because of the operational model of FPM, I think that this idea would greatly improve the SAPI, especially as part of a development idea. Definitely a +1 to that idea. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
