We are experiencing some problems with persistent sockets (the kind you get
from pfsockopen) and I can't help but conclude that some semantic changes
are needed to make them dependable. (That is, assuming anyone cares whether
they are dependable.)
The problem is that, in practice, a persistent socket can be handed from one
script to the next in virtually any state. If one script begins some
transaction on a pfsocket, it's not in an "idle" state that can be handed to
another script until the transaction is completely done. For example, if
you do an HTTP GET on a pfsocket (assuming Keep-Alive), no other script
should be able to obtain that socket until the reply has been received and
fully consumed by the first script. But if the first script failed to do
that for any reason, the next script that comes along receives the socket in
a state that it can't use. It may post it's own HTTP "GET" and then receive
the reply from the last script's uncompleted GET. And after that, the next
script STILL receives a socket in a bad state, ad infinitum.
..and I'll add that this happens to us on a weekly basis. Windows Server
2003, IIS 6, PHP 5.2.5, isapi.
If it's possible for a script to detect that it's received a socket in a
non-idle state, it should be allowed to close it (really, truly close it),
at the very least to remove it from the pool of persistent sockets to the
given resource. But unless I've missed something, it's not possible to
really close a pfsocket. It just gets returned to the resource pool, in
whatever sorry state it's in.
Here's the big part: I was thinking that a semantic change to persistent
sockets might make it easier for scripts to work "correctly" without
bothering them too much. The change is this: If a script doesn't "fclose"
it's "pfsockopen"ed socket, it gets closed for real when the script ends.
I suggest this because I think it would make scripts "just work" in the
presence of failures, even if the script coder doesn't completely understand
the principle; it makes the transaction boundaries "automatic". The down
side is that, if a script forgets the fclose, things work but it doesn't
recycle sockets, it makes new ones all the time.
The other down side is that for old scripts that never had an fclose in
them, they stop getting recycled pfsockets until the fclose is added.
I'm going to do something about this myself, anyway. I'd really like it
if a solution were adopted into the main code base.
Here's the big part: I was thinking that a semantic change to
persistent
sockets might make it easier for scripts to work "correctly" without
bothering them too much. The change is this: If a script doesn't
"fclose"
it's "pfsockopen"ed socket, it gets closed for real when the
script ends.I suggest this because I think it would make scripts "just work" in
the
presence of failures, even if the script coder doesn't completely
understand
the principle; it makes the transaction boundaries "automatic". The
down
side is that, if a script forgets the fclose, things work but it
doesn't
recycle sockets, it makes new ones all the time.The other down side is that for old scripts that never had an fclose
in
them, they stop getting recycled pfsockets until the fclose is added.I'm going to do something about this myself, anyway. I'd really
like it
if a solution were adopted into the main code base.
I think this might generally be a solution to make persistent
connections less error prone in PHP. This includes database extensions
as well. However it does strike me as something that should be done in
a major PHP version ..
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Lukas Kahwe Smith schreef:
Here's the big part: I was thinking that a semantic change to persistent
sockets might make it easier for scripts to work "correctly" without
bothering them too much. The change is this: If a script doesn't
"fclose"
it's "pfsockopen"ed socket, it gets closed for real when the script
ends.I suggest this because I think it would make scripts "just work" in the
presence of failures, even if the script coder doesn't completely
understand
the principle; it makes the transaction boundaries "automatic". The down
side is that, if a script forgets the fclose, things work but it doesn't
recycle sockets, it makes new ones all the time.The other down side is that for old scripts that never had an fclose in
them, they stop getting recycled pfsockets until the fclose is added.I'm going to do something about this myself, anyway. I'd really
like it
if a solution were adopted into the main code base.I think this might generally be a solution to make persistent
connections less error prone in PHP. This includes database extensions
as well. However it does strike me as something that should be done in a
major PHP version ..
would it not be less intrusive to offer a pfclose() in a combination with
something like use_pfclose()? where by any persistent handles opened after
a call to use_pfclose() would require a pfclose() or other be truly closed
as per Richard suggestion.
In this way the "just works" principle is upheld, and there is no need
to change anything in the current behaviour. A developer can actively choose
to implement persistence state protection or whatever it might be called
outside my kingdom :-)
In addition this allows for a possible semantic change of fclose() to
allow actually closing persistent connections?
[sorry for the noise.]
regards,
Lukas Kahwe Smith
mls@pooteeweet.org