struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tamás Faragó (JIRA) <j...@apache.org>
Subject [jira] [Updated] (WW-4986) Race condition reloading config results in actions not found
Date Thu, 22 Nov 2018 10:46:00 GMT

     [ https://issues.apache.org/jira/browse/WW-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Tamás Faragó updated WW-4986:
-----------------------------
    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. 

  was:
Issue only occurs when the following xml configuration is present :

“struts.configuration.xml.reload” is enabled.

 

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. 


> Race condition reloading config results in actions not found
> ------------------------------------------------------------
>
>                 Key: WW-4986
>                 URL: https://issues.apache.org/jira/browse/WW-4986
>             Project: Struts 2
>          Issue Type: Bug
>          Components: XML Configuration
>    Affects Versions: 2.5.18
>            Reporter: Tamás Faragó
>            Priority: Major
>              Labels: 404-error, action, race-condition, reloading
>             Fix For: 2.5.x
>
>
> 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. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message