[jira] [Commented] (TS-1969) Mechanism to perform a graceful restart of trafficserver

["Leif Hedstrom (JIRA)" <ji...@apache.org>]

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

Leif Hedstrom commented on TS-1969:
-----------------------------------

There's some stub code in the core, that is called, but does nothing, which seems to be at least related to this:

{code}

bool
HttpTransact::service_transaction_in_proxy_only_mode(State* /* s ATS_UNUSED */)
{
  return false;
}

{code}
                
> Mechanism to perform a graceful restart of trafficserver
> --------------------------------------------------------
>
>                 Key: TS-1969
>                 URL: https://issues.apache.org/jira/browse/TS-1969
>             Project: Traffic Server
>          Issue Type: New Feature
>            Reporter: Kris Lindgren
>             Fix For: 3.5.0
>
>
> For example HAproxy has the ability to start a new HAproxy instance to tell the old one to temporarily disconnect from the socket so the new process can take it over.  If startup was successful then new connections are handled by the new HAproxy instance and old connections are handled by the old HAproxy instance.  Once all the old connections have finished the old instance terminates.
> I am currently using 3.2.4 and am trying to mitigate the breaking of existing connections when restarting. Specifically around adding a new SSL cert, but It would also be nice to mitigate breaking of connections when changing listen ports as well, or when you change certain configurations options that require a restart.  I understand that the current 3.3.x branch should have a feature to re-read the ssl certs without requiring a restart.
> One possible issue with the above model is that the cache could only be owned by one process.  It would be nice if the old process would degrade into read-only or a proxy-only mode.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira