[
https://issues.apache.org/jira/browse/THRIFT-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volodymyr Panivko closed THRIFT-2151.
-------------------------------------
Resolution: Fixed
Merged into apache/thrift master on 2026-09-11:
https://github.com/apache/thrift/pull/3796. Closing the issue after merge. The
merged change adds regression coverage for the existing persistent socket close
behavior and repairs the PHP test harness so warnings cannot hide subsequent
tests.
> PHP Thrift library provides persistent socket option that cannot be recovered
> from network failure
> --------------------------------------------------------------------------------------------------
>
> Key: THRIFT-2151
> URL: https://issues.apache.org/jira/browse/THRIFT-2151
> Project: Thrift
> Issue Type: Bug
> Components: PHP - Library
> Affects Versions: 0.9.1
> Environment: PHP running as apache module
> Reporter: Paul Banks
> Assignee: Volodymyr Panivko
> Priority: Major
> Labels: easyfix
> Original Estimate: 1h
> Time Spent: 40m
> Remaining Estimate: 20m
>
> The TSocket class has a 'persistent' mode which uses PHP's pfsockopen()
> function to create or connect to a socket.
> Problem is that PHP's persistent sockets DO NOT get automatically dropped if
> the other end of the connection goes away. You just get failures (i.e.
> Exceptions thrown by thrift) when trying to read or write from them.
> So far that is fair enough. The problem is that the only way to recover from
> network failure (or remote server failure) is to fclose() the persistent
> socket and re-open it. This is currently impossible since TSocket::close()
> method is explicitly a no-op for persistent sockets.
> I propose either adding an optional argument to close() that forces even a
> persistent socket to close, or add a new method to PHP class called
> reconnect() or similar.
> I've not used other client libs so I'm not sure how differences in API work
> across different client languages but I guess PHP may be the only language
> that has concept of persistent sockets at all?
> For the record this was discovered in a production large scale web-app where
> most requests on our apache-based web tier end up logging one or more
> messages to scribe. Persistent sockets are prefered for speed and resource
> efficiency. Whenever a scribe daemon restarts (for config change or upgrade
> for example) we have a problem that there is no way for failed log messages
> to close and re-open the connection. Worse all other requests served by the
> same apache process also fail to write to the broken socket even long after
> the daemon has successfully restarted and is available. Until the apache
> process is recycled or clears it's open persistent connections (which takes
> up to 30 mins) no requests can log to scribe.
> I realise even with the suggested change, using persistent sockets will
> require that read/write errors are caught and the socket explicitly recycled.
> Right now that is only possible if we modify the thrift library as described
> above.
> I would be happy to submit a patch it should be a trivial change however
> would appreciate input on the prefered changes to the PHP API from someone
> with insight about all the APIs and documentation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
