bneradt commented on issue #7204: URL: https://github.com/apache/trafficserver/issues/7204#issuecomment-698001250
Digging further, what is described here as a problem with auto deletion using the old config looks like just one of a host of like problems that happen as LogObject and LogBuffer objects are created based upon values from the old config. Basically, all objects created in new_config->init in [Log.cc](https://github.com/apache/trafficserver/blob/bd089772b735bc374c0f0f4fedccabd1e6a30cda/proxy/logging/Log.cc#L117) are created referencing the old rather than the new config (the `// <--` comments are added as annotations by me): ``` new_config = new LogConfig; ink_assert(new_config != nullptr); new_config->read_configuration_variables(); // <-- New config has new user-supplied values. // grab the _APImutex so we can transfer the api objects to // the new config // ink_mutex_acquire(prev->log_object_manager._APImutex); Debug("log-api-mutex", "Log::change_configuration acquired api mutex"); new_config->init(Log::config); // <-- LogObject and LogBuffer objects are created here, // but as they are created they reference the old Log::config. // Make the new LogConfig active. ink_atomic_swap(&Log::config, new_config); // <-- Only here is Log::config updated. ``` Thus, for example, if the user changes the max buffer size and does a config reload, LogObjects will instead be configured to use the old max buffer size. While fixing the problem with rolled log auto deletion, we should consider fixing these issues with LogObject and LogBuffer as well. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
