You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Tim Canavan (JIRA)" <ji...@apache.org> on 2012/05/08 21:51:48 UTC
[jira] [Created] (CONFIGURATION-496) Excessive Synchronization
AbstractFileConfiguration
Tim Canavan created CONFIGURATION-496:
-----------------------------------------
Summary: Excessive Synchronization AbstractFileConfiguration
Key: CONFIGURATION-496
URL: https://issues.apache.org/jira/browse/CONFIGURATION-496
Project: Commons Configuration
Issue Type: Bug
Components: File reloading
Affects Versions: 1.8, 1.7, 1.6
Reporter: Tim Canavan
We are having a problem with commons configuration 1.6 AbstractFileConfiguration
During a stress test we are seeing that we have wait locks against this method causing this method not to complete for up to one second.
We are using the FileReloadStrategy delegate which makes a check on the file system when now + interval is greater than the compare time.
Why can't we make this check before the synchronized block thus increasing throughput. I have noticed in 1.8 that the caller to this method is synchronized. This seems like excessive synchronization. Any ideas how to solve this.
public void reload()
{
synchronized (reloadLock)
{
if (noReload == 0)
{
try
{
enterNoReload(); // avoid reentrant calls
if (strategy.reloadingRequired())
{
if (getLogger().isInfoEnabled())
{
getLogger().info("Reloading configuration. URL is " + getURL());
}
fireEvent(EVENT_RELOAD, null, getURL(), true);
setDetailEvents(false);
boolean autoSaveBak = this.isAutoSave(); // save the current state
this.setAutoSave(false); // deactivate autoSave to prevent information loss
try
{
clear();
load();
}
finally
{
this.setAutoSave(autoSaveBak); // set autoSave to previous value
setDetailEvents(true);
}
fireEvent(EVENT_RELOAD, null, getURL(), false);
// notify the strategy
strategy.reloadingPerformed();
}
}
catch (Exception e)
{
fireError(EVENT_RELOAD, null, null, e);
// todo rollback the changes if the file can't be reloaded
}
finally
{
exitNoReload();
}
}
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONFIGURATION-496) Excessive Synchronization
AbstractFileConfiguration
Posted by "Ralph Goers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONFIGURATION-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13270831#comment-13270831 ]
Ralph Goers commented on CONFIGURATION-496:
-------------------------------------------
There is no simple answer to your question. Commons Configuration used to not be thread-safe. Unfortunately, I discovered that after our application was already in production. My use case deals with DefaultConfigurationBuilder constructing DynamicCombinedConfigurations and XMLConfigurations all with file reloading. Due to the way CombinedConfigurations work every time a configuration file was reloaded other configurations that shared the common file were corrupted.
Unfortunately, you can't check to see if a reload is required without holding the lock or multiple threads will end up performing the reload.
All of this was put into place while the minimum version was Java 1.4. Now that it is Java 5 much of this code can be redone to take advantage of java.util.concurrent. I just haven't gotten to it. However, I've had reports of similar issues from my users so I plan to address these issues in the very near future.
> Excessive Synchronization AbstractFileConfiguration
> ---------------------------------------------------
>
> Key: CONFIGURATION-496
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-496
> Project: Commons Configuration
> Issue Type: Bug
> Components: File reloading
> Affects Versions: 1.6, 1.7, 1.8
> Reporter: Tim Canavan
>
> We are having a problem with commons configuration 1.6 AbstractFileConfiguration
> During a stress test we are seeing that we have wait locks against this method causing this method not to complete for up to one second.
> We are using the FileReloadStrategy delegate which makes a check on the file system when now + interval is greater than the compare time.
> Why can't we make this check before the synchronized block thus increasing throughput. I have noticed in 1.8 that the caller to this method is synchronized. This seems like excessive synchronization. Any ideas how to solve this.
> {code}
> public void reload()
> {
> synchronized (reloadLock)
> {
> if (noReload == 0)
> {
> try
> {
> enterNoReload(); // avoid reentrant calls
> if (strategy.reloadingRequired())
> {
> if (getLogger().isInfoEnabled())
> {
> getLogger().info("Reloading configuration. URL is " + getURL());
> }
> fireEvent(EVENT_RELOAD, null, getURL(), true);
> setDetailEvents(false);
> boolean autoSaveBak = this.isAutoSave(); // save the current state
> this.setAutoSave(false); // deactivate autoSave to prevent information loss
> try
> {
> clear();
> load();
> }
> finally
> {
> this.setAutoSave(autoSaveBak); // set autoSave to previous value
> setDetailEvents(true);
> }
> fireEvent(EVENT_RELOAD, null, getURL(), false);
> // notify the strategy
> strategy.reloadingPerformed();
> }
> }
> catch (Exception e)
> {
> fireError(EVENT_RELOAD, null, null, e);
> // todo rollback the changes if the file can't be reloaded
> }
> finally
> {
> exitNoReload();
> }
> }
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CONFIGURATION-496) Excessive Synchronization
AbstractFileConfiguration
Posted by "Tim Canavan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONFIGURATION-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tim Canavan updated CONFIGURATION-496:
--------------------------------------
Description:
We are having a problem with commons configuration 1.6 AbstractFileConfiguration
During a stress test we are seeing that we have wait locks against this method causing this method not to complete for up to one second.
We are using the FileReloadStrategy delegate which makes a check on the file system when now + interval is greater than the compare time.
Why can't we make this check before the synchronized block thus increasing throughput. I have noticed in 1.8 that the caller to this method is synchronized. This seems like excessive synchronization. Any ideas how to solve this.
{code}
public void reload()
{
synchronized (reloadLock)
{
if (noReload == 0)
{
try
{
enterNoReload(); // avoid reentrant calls
if (strategy.reloadingRequired())
{
if (getLogger().isInfoEnabled())
{
getLogger().info("Reloading configuration. URL is " + getURL());
}
fireEvent(EVENT_RELOAD, null, getURL(), true);
setDetailEvents(false);
boolean autoSaveBak = this.isAutoSave(); // save the current state
this.setAutoSave(false); // deactivate autoSave to prevent information loss
try
{
clear();
load();
}
finally
{
this.setAutoSave(autoSaveBak); // set autoSave to previous value
setDetailEvents(true);
}
fireEvent(EVENT_RELOAD, null, getURL(), false);
// notify the strategy
strategy.reloadingPerformed();
}
}
catch (Exception e)
{
fireError(EVENT_RELOAD, null, null, e);
// todo rollback the changes if the file can't be reloaded
}
finally
{
exitNoReload();
}
}
}
}
{code}
was:
We are having a problem with commons configuration 1.6 AbstractFileConfiguration
During a stress test we are seeing that we have wait locks against this method causing this method not to complete for up to one second.
We are using the FileReloadStrategy delegate which makes a check on the file system when now + interval is greater than the compare time.
Why can't we make this check before the synchronized block thus increasing throughput. I have noticed in 1.8 that the caller to this method is synchronized. This seems like excessive synchronization. Any ideas how to solve this.
public void reload()
{
synchronized (reloadLock)
{
if (noReload == 0)
{
try
{
enterNoReload(); // avoid reentrant calls
if (strategy.reloadingRequired())
{
if (getLogger().isInfoEnabled())
{
getLogger().info("Reloading configuration. URL is " + getURL());
}
fireEvent(EVENT_RELOAD, null, getURL(), true);
setDetailEvents(false);
boolean autoSaveBak = this.isAutoSave(); // save the current state
this.setAutoSave(false); // deactivate autoSave to prevent information loss
try
{
clear();
load();
}
finally
{
this.setAutoSave(autoSaveBak); // set autoSave to previous value
setDetailEvents(true);
}
fireEvent(EVENT_RELOAD, null, getURL(), false);
// notify the strategy
strategy.reloadingPerformed();
}
}
catch (Exception e)
{
fireError(EVENT_RELOAD, null, null, e);
// todo rollback the changes if the file can't be reloaded
}
finally
{
exitNoReload();
}
}
}
}
> Excessive Synchronization AbstractFileConfiguration
> ---------------------------------------------------
>
> Key: CONFIGURATION-496
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-496
> Project: Commons Configuration
> Issue Type: Bug
> Components: File reloading
> Affects Versions: 1.6, 1.7, 1.8
> Reporter: Tim Canavan
>
> We are having a problem with commons configuration 1.6 AbstractFileConfiguration
> During a stress test we are seeing that we have wait locks against this method causing this method not to complete for up to one second.
> We are using the FileReloadStrategy delegate which makes a check on the file system when now + interval is greater than the compare time.
> Why can't we make this check before the synchronized block thus increasing throughput. I have noticed in 1.8 that the caller to this method is synchronized. This seems like excessive synchronization. Any ideas how to solve this.
> {code}
> public void reload()
> {
> synchronized (reloadLock)
> {
> if (noReload == 0)
> {
> try
> {
> enterNoReload(); // avoid reentrant calls
> if (strategy.reloadingRequired())
> {
> if (getLogger().isInfoEnabled())
> {
> getLogger().info("Reloading configuration. URL is " + getURL());
> }
> fireEvent(EVENT_RELOAD, null, getURL(), true);
> setDetailEvents(false);
> boolean autoSaveBak = this.isAutoSave(); // save the current state
> this.setAutoSave(false); // deactivate autoSave to prevent information loss
> try
> {
> clear();
> load();
> }
> finally
> {
> this.setAutoSave(autoSaveBak); // set autoSave to previous value
> setDetailEvents(true);
> }
> fireEvent(EVENT_RELOAD, null, getURL(), false);
> // notify the strategy
> strategy.reloadingPerformed();
> }
> }
> catch (Exception e)
> {
> fireError(EVENT_RELOAD, null, null, e);
> // todo rollback the changes if the file can't be reloaded
> }
> finally
> {
> exitNoReload();
> }
> }
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira