[jira] [Commented] (THRIFT-2151) PHP Thrift library provides persistent socket option that cannot be recovered from network failure

["Benjamin Heiskell (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/THRIFT-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16211167#comment-16211167 ] 

Benjamin Heiskell commented on THRIFT-2151:
-------------------------------------------

Is this issue addressed by THRIFT-4154?

https://github.com/apache/thrift/commit/c6ded922c586cad7f66b57a123fec520e5c36a5e#diff-883bc42e2b42573c9e92046a6c56d7cb

> 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
>              Labels: easyfix
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> 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
(v6.4.14#64029)