You are using the global configuration to access an overridable configuration. Which means, someone would think they are overriding the configuration, buy get the global configuration value from records.config anyways.
I spoke with amc about this and agreed that it should be possible to implement this in a way that retains the overridable property of the configuration. I hope that makes sense? > On Mar 12, 2015, at 4:27 PM, Dzmitry Markovich (JIRA) <[email protected]> wrote: > > > [ > https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14359547#comment-14359547 > ] > > Dzmitry Markovich edited comment on TS-3312 at 3/12/15 10:26 PM: > ----------------------------------------------------------------- > > Agree with HttpConfig::release. Maybe I'm missing something, but I don see > how it breaks "previously overridable configuration into a non-overridable > one"? I'll talk to Alan offline and will update this ticket... > > > was (Author: dmich): > Agree with HttpConfig::release. Maybe I'm missing something, but I don see > how it breaks "previously overridable configuration into a non-overridable > one"? I'll talk to Alan offline... > >> KA timeout to origin does not seem to honor configurations >> ---------------------------------------------------------- >> >> Key: TS-3312 >> URL: https://issues.apache.org/jira/browse/TS-3312 >> Project: Traffic Server >> Issue Type: Bug >> Components: Core, HTTP >> Reporter: Leif Hedstrom >> Assignee: Brian Geffon >> Fix For: 5.3.0 >> >> Attachments: keep_alive_timeout.diff >> >> >> Doing some basic testing, with the following settings: >> {code} >> CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 120 >> CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30 >> {code} >> I see ATS timing out the origin sessions after 30sec, with a >> {code} >> CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30 >> {code} >> What's also interesting, after I made a config change per Geffon's >> suggestion: >> {code} >> CONFIG proxy.config.http.origin_min_keep_alive_connections INT 10 >> {code} >> I see the following in the diagnostic trace: >> {code} >> [Jan 21 14:19:19.416] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] [release >> session] session placed into shared pool >> [Jan 21 14:19:49.558] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] >> [session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT], >> reseting timeout to maintain minimum number of connections >> [Jan 21 14:20:19.633] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] >> [session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT], >> reseting timeout to maintain minimum number of connections >> [Jan 21 14:20:19.670] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] >> [session_pool] session 0x1cc5aa0 received io notice [VC_EVENT_EOS] >> {code} >> So, not only is it resetting the timeout twice, it also gets a VC_EVENT_EOS. >> I first though it was the origin that closed the connection, but from what I >> could tell, the timeout on the origin was set to 60s. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.4#6332)
