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

James Peach commented on TS-3364:
---------------------------------

This worries me. Options (2) and (3) are basically asking for non-determinism. 
Loading a partially-formed config file could open up security holes or have 
serious user impact, whereas failing on startup limits the damage to a service 
outage. In the general case, it's not possible to know whether it is safe to 
continue.

Maybe the better way to approach this is to enhance the alarms system so that 
whatever is managing the bad configuration can take some action?

> 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.url_remap.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