[jira] [Updated] (CONFIGURATION-496) Excessive Synchronization AbstractFileConfiguration
[
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
[jira] [Commented] (CONFIGURATION-496) Excessive Synchronization AbstractFileConfiguration
[
https://issues.apache.org/jira/browse/CONFIGURATION-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] (MATH-753) Better implementation for the gamma distribution density function
[
https://issues.apache.org/jira/browse/MATH-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard updated MATH-753:
---
Attachment: lanczos.patch
{{lanczos.patch}} is the patch discussed in the the {{dev}} mailing-list:
{quote}
As I initially feared, what was proposed in the JIRA ticket leads to high
floating point errors. I adapted a method proposed in
[BOOST|http://www.boost.org/doc/libs/1_35_0/libs/math/doc/sf_and_dist/html/math_toolkit/special/sf_gamma/igamma.html]
(formula (15))
with acceptable errors. Meanwhile, I've also managed to improve the accuracy of
the computation of the density for the range of parameters where the previous
implementation was already working: in this range, the accuracy _was_ about 300
ulps, and is now 1-2 ulps! {color:red}Note: I might have been too optimistic,
here. There is a significant improvement, though{color}. I think this
improvement is worth implementing.
The downside is that I need to expose the Lanczos implementation internally
used by {{o.a.c.m3.special.Gamma}}. This approximation is so standard that I
don't see it as a problem. I don't think that it reveals too much of the Gamma
internals, since the javadoc of {{Gamma.logGamma}} states that it uses this
approximation. So what I
propose is the addition of two methods in {{Gamma}}:
* {{double getLanczosG()}}: returns the {{g}} constant
* {{double lanczos(double)}}: returns the value of the Lanczos sum.
{quote}
Better implementation for the gamma distribution density function
-
Key: MATH-753
URL: https://issues.apache.org/jira/browse/MATH-753
Project: Commons Math
Issue Type: Improvement
Affects Versions: 2.2, 3.0, 3.1
Reporter: Francesco Strino
Assignee: Sébastien Brisard
Priority: Minor
Labels: improvement, stability
Fix For: 3.1
Attachments: lanczos.patch
The way the density of the gamma distribution function is estimated can be
improved.
It's much more stable to calculate first the log of the density and then
exponentiate, otherwise the function returns NaN for high values of the
parameters alpha and beta.
It would be sufficient to change the public double density(double x) function
at line 204 in the file
org.apache.commons.math.distribution.GammaDistributionImpl as follows:
return Math.exp(Math.log( x )*(alpha-1) - Math.log(beta)*alpha - x/beta -
Gamma.logGamma(alpha));
In order to improve performance, log(beta) and Gamma.logGamma(alpha) could
also be precomputed and stored during initialization.
--
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
