[WW-4986] Race condition reloading config results in actions not found

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Duplicate
• Affects Version/s: 2.5.18
• Fix Version/s: 2.5.20, 6.0.0
• Component/s: XML Configuration
• Labels: 404-error action race-condition reloading
• Assignee: Yasser Zamani
• Reporter: Tamás Faragó
• Created: 22/Nov/18 10:42
• Updated: 02/Nov/21 06:08
• Resolved: 02/Dec/18 07:28

Description

Issue only occurs when the following xml configuration is present :

“struts.configuration.xml.reload” is set to true .

 

The reload flag is supposed to reload the xml configuration when it changes. To this end it calls the synchronized method com.opensymphony.xwork2.config.impl.DefaultConfiguration::reloadContainer. This clears out the packageContext map. The issue is that this operation is not thread safe as none of the other accessors of this map (for example com.opensymphony.xwork2.config.impl.DefaultConfiguration::getPackageConfigs which is the cause of the disappearing actions) is not synchronized .

A solution would be totally rebuild the context into a separate temporary object and reassign it at the end.

 

 

To make matters worse is that this reloading happens on almost every single request due to some other race condition which I haven't figured out yet.

• For some reason DefaultFileManagerFactory (which is not a singleton) fails to properly set DefaultFileManagerFactory::setReloadingConfigs from the XML thus reloadConfigs is false which causes DefaultFileManager::setReloadingConfigs to be false, which means that when struts doesn’t monitor files (DefaultFileManager::monitorFile) and the files cache is empty.
• Now this would work, but the code that calls DefaultFileManager::fileNeedsReloading and DefaultFileManager::loadFile is a different instance of this class, where the first one has reloadingConfigs set to true, and in the second one to false.
• Somewhere in XWorkConverter::SetFileManagerFactory > DefaultFileManagerFactory::getFileManager > DefaultFileManager::setReloadingConfigs using the same stack (at least to this level) the configuration is not read properly. 

Issue Links

• Blocked: WW-4974 NullPointerException in DefaultStaticContentLoader#findStaticResource