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

Leif Hedstrom commented on TS-3364:
-----------------------------------

Also, what we're kinda lacking is loading of "units" of configurations. In the 
Varnish case, if the VCL file doesn't compile properly, I'd imagine it would 
refuse to try to load the .so. That doesn't prevent someone from doing a bad 
mistake, but at least it doesn't let you fuck up the entire system. That would 
help isolating errors to "units" (vhosts or whatever you want to call it).

Implementing this seems like a pretty serious undertaking though.

> Add configuration to control traffic_server's reaction to fatal errors  
> during (re)loading the config files.
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: TS-3364
>                 URL: https://issues.apache.org/jira/browse/TS-3364
>             Project: Traffic Server
>          Issue Type: Improvement
>          Components: Configuration
>    Affects Versions: 5.3.0
>            Reporter: Sudheer Vinukonda
>
> Currently, traffic_server fails to initialize when it encounters fatal errors 
> in loading the config files during start up. During dynamic reloading of 
> config files (e.g. via traffic_line), traffic_server rejects new config and 
> falls back to existing/old config (however, if there was a traffic_server 
> crash/restart subsequently, that can again result into failing to initialize).
> This jira proposes to make the behavior of traffic_server when it encounters 
> such fatal errors configurable via a new setting 
> {{proxy.config.ignore_fatal_errors}} with the below options:
> {code}
> 0 : All errors are fatal, do not load/reload
> 1 : Ignore a bad config line, continue with the rest
> 2 : Ignore a bad config line, stop parsing the file further
> ..
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to