[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-user
Subject:    Re: [configuration] Calling getConfiguration on DefaultConfigurationBuilder more than once permitted
From:       dont_know <dont_know () gmx ! net>
Date:       2014-03-23 22:11:14
Message-ID: 532F5C02.6040005 () gmx ! net
[Download RAW message or body]

Hi Oliver,

yes, you are right. My problem was that no reload happens when one or more of the \
property files were changed. So I called getConfiguration on the \
DefaultConfigurationBuilder to reload the properties. And this leads to heavy file \
access because every call to getConfiguration adds ten file accesses additionally per \
call: first call -> 10 file accesses
second call -> 20 file accesses
third call -> 30 file accesses
100th call -> 1000 file accesses

By defining the forceReloadCheck flag and a ReloadStrategy this problem doesn't \
occure anymore and I can use a single instance of Configuration which automatically \
reflects the changed properties.

Unluckily the example with ten same property files was bad. In my real use case I use \
references to ten different property files.

Stefan

Hi,

Am 23.03.2014 18:17, schrieb dont_know:
> Hi Martin,
> 
> I hope you haven't missunderstood me: the behaviour of
> DefaultConfigurationBuilder is ugly, not your solution ;)
> 
> But I think you have overlooked the second important part in the
> config.xml -> the definition of a ReloadStrategy for the referenced
> properties. This did the trick and I want my queen back :)

I don't play Chess, but I am also not sure whether I understand your
solution.

So, your complaint is that DefaultConfigurationBuilder reads the source
file too often, right? Well, we could add logic to avoid that the same
configuration source is read multiple times. However, loading one
configuration file ten times in a builder definition is certainly not
the intended use case. Typically, you read different configuration
files, and then the builder has no other chance than reading them one by
one. In your scenario you are better off by creating the
CombinedConfiguration yourself from a configuration file read manually.

IIUC, your problem was that no reloads happened when the source file was
changed by another process. Therefore, you had to re-create the
configuration from the builder each time you want to access it. By
setting the forceReloadCheck flag, this is no longer necessary because
reloads are now detected. Is this correct?

Oliver

> 
> Am 22.03.2014 23:55, schrieb Martin Gainty:
> 
> > Date: Sat, 22 Mar 2014 22:39:14 +0100
> > From: dont_know@gmx.net
> > To: user@commons.apache.org
> > Subject: Re: [configuration] Calling getConfiguration on
> > DefaultConfigurationBuilder more than once permitted
> > 
> > Hi Martin,
> > 
> > I found a solution which fits my requirements without this ugly
> > behaviour as described before. The trick is to configure the reloading
> > strategy and force the reload checking in "config.xml":
> > <?xml version="1.0" encoding="ISO-8859-1" ?>
> > 
> > <configuration>
> > <header>
> > <result forceReloadCheck="true"/>
> > </header>
> > 
> MG>lets find out what forceReloadCheck and what it does
> MG>/commons-configuration>grep -r -l forceReloadCheck *.*
> .\src\main\java\org\apache\commons\configuration\CombinedConfiguration.java
> .\target\classes\org\apache\commons\configuration\CombinedConfiguration.class
> 
> 
> MG>forceReloadCheck has NO effect on
> DefaultConfigurationBuilder.getConfiguration()
> protected CombinedConfiguration createAdditionalsConfiguration(
> CombinedConfiguration resultConfig)
> {
> CombinedConfiguration addConfig =
> new CombinedConfiguration(new UnionCombiner()); //this will
> STILL pull UNION of entities
> 
> addConfig.setDelimiterParsingDisabled(resultConfig
> .isDelimiterParsingDisabled());
> addConfig.setForceReloadCheck(resultConfig.isForceReloadCheck());
> addConfig.setIgnoreReloadExceptions(resultConfig
> .isIgnoreReloadExceptions());
> return addConfig;
> }
> MG>if this was chess ..i have just taken your queen
> MG>your move..
> 
> > </configuration>
> > 
> > That just made my day :)
> > 
> > Thanks for your effort
> > Stefan
> > 
> > Am 22.03.2014 02:17, schrieb Martin Gainty:
> > > 
> > > 
> > > 
> > > > Date: Fri, 21 Mar 2014 22:45:29 +0100
> > > > From: dont_know@gmx.net
> > > > To: user@commons.apache.org
> > > > Subject: [configuration] Calling getConfiguration on
> > DefaultConfigurationBuilder more than once permitted
> > > > 
> > > > Hi,
> > > > 
> > > > is it permitted to call getConfiguration more than once on the same
> > > > instance of DefaultConfigurationBuilder like this:
> > > > 
> > > > DefaultConfigurationBuilder builder = new
> > DefaultConfigurationBuilder();
> > > > builder.setFile(new File("config.xml"));
> > > > Configuration config = builder.getConfiguration(true);
> > > > config = builder.getConfiguration(true);
> > > > config = builder.getConfiguration(true);
> > > > ...
> > > > 
> > > > The config.xml looks like this:
> > > > <?xml version="1.0" encoding="ISO-8859-1" ?>
> > > > 
> > > > <configuration>
> > > > <properties fileName="test.properties" config-at="a"/>
> > > > <properties fileName="test.properties" config-at="b"/>
> > > > <properties fileName="test.properties" config-at="c"/>
> > > > <properties fileName="test.properties" config-at="d"/>
> > > > <properties fileName="test.properties" config-at="e"/>
> > > > <properties fileName="test.properties" config-at="f"/>
> > > > <properties fileName="test.properties" config-at="g"/>
> > > > <properties fileName="test.properties" config-at="h"/>
> > > > <properties fileName="test.properties" config-at="i"/>
> > > > <properties fileName="test.properties" config-at="j"/>
> > > > </configuration>
> > > > 
> > > > and the referenced file "test.properties" contains:
> > > > a=a
> > > > b=b
> > > > c=c
> > > > 
> > > > I asked this question, because with the first call of getConfiguration
> > > > the "test.properties"-file is read 10 times (once for every
> > > > "config-at"), with the second call 20 times, with the third call 30
> > > > times and so on. So in the end the program slows down and after 100
> > > > calls it needs 200ms to read the properties.
> > > 
> > > MG>builder.getConfiguration(true) a Union between one DB Table and
> > another DB Table
> > > MG>if you want to 'merge' 2 groups together I suggest using
> > OverrideCombiner
> > > MG>ConfigurationNode combine(ConfigurationNode node1,
> > ConfigurationNode node2)
> > > MG>
> > http://www.docjar.com/html/api/org/apache/commons/configuration/tree/OverrideCombiner.java.html
> >  
> > > > I'm a little bit confused because my idea was to instantiate
> > > > DefaultConfigurationBuilder for performance reasons only once (as a
> > > > Singleton) and call getConfiguration subsequently to read "fresh"
> > > > properties.
> > > > 
> > > > Thanks
> > > > Stefan
> > > > 
> > > > 
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: user-help@commons.apache.org
> > > > 
> > > 
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> > For additional commands, e-mail: user-help@commons.apache.org
> > 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]