You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by WANG Qingtian <qi...@gmail.com> on 2005/04/04 23:47:42 UTC
Configuration - Reload Strategy in j2ee containers
Hi,
Is the reload strategy implemented by creating a thread that
periodically checks the time stamp of the configuration file? If so, how
do I make sure that thread is started/stopped properly when I use it in
a j2ee container? Like, will the thread be killed when I shut down the
web/ejb container? What is the "best practice" of using "configuration"
in a j2ee container?
Thanks a lot for your help!!!
Qingtian
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Configuration - Reload Strategy in j2ee containers
Posted by Soaring Eagle <co...@gmail.com>.
Thank you Emmanuel.
On Apr 6, 2005 5:41 PM, Emmanuel Bourg <eb...@apache.org> wrote:
> Soaring Eagle wrote:
>
> > Thanks Emmanuel. But how does commons cache this timestamp? If it is a
> > singleton, how does commons ensure that the instance is always in
> > memory? For example, such a time interval could be set to many days
> > (concievably). How do ensure that the instance is not garbage
> > collected before the interval arrives?
>
> A ReloadingStrategy is assigned to the FileConfiguration, and the
> ReloadingStrategy keeps the timestamp. So as long as you keep a
> reference to your configuration, it will not be garbage collected.
>
> Emmanuel Bourg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Configuration - Reload Strategy in j2ee containers
Posted by Emmanuel Bourg <eb...@apache.org>.
Soaring Eagle wrote:
> Thanks Emmanuel. But how does commons cache this timestamp? If it is a
> singleton, how does commons ensure that the instance is always in
> memory? For example, such a time interval could be set to many days
> (concievably). How do ensure that the instance is not garbage
> collected before the interval arrives?
A ReloadingStrategy is assigned to the FileConfiguration, and the
ReloadingStrategy keeps the timestamp. So as long as you keep a
reference to your configuration, it will not be garbage collected.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Configuration - Reload Strategy in j2ee containers
Posted by Soaring Eagle <co...@gmail.com>.
Thanks Emmanuel. But how does commons cache this timestamp? If it is a
singleton, how does commons ensure that the instance is always in
memory? For example, such a time interval could be set to many days
(concievably). How do ensure that the instance is not garbage
collected before the interval arrives?
On Apr 6, 2005 4:42 PM, Emmanuel Bourg <eb...@apache.org> wrote:
> Soaring Eagle wrote:
>
> > How does commons configuration determine when the interval is done
> > without caching at least the timestamp of the last read? In other
> > words, without threading, how does commons cache any data? If I know
> > how, then I will surely use this feature from commons rather than
> > writing my own logic.
>
> Commons Configuration keeps the timestamp of the last file check. On
> accessing a property (by calling getString(), getInt(), etc), the file
> is checked again if a specified delay is elapsed since the last check.
> Of course the configuration is not reloaded after this delay if the file
> didn't change.
>
> Emmanuel Bourg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Configuration - Reload Strategy in j2ee containers
Posted by Emmanuel Bourg <eb...@apache.org>.
Soaring Eagle wrote:
> How does commons configuration determine when the interval is done
> without caching at least the timestamp of the last read? In other
> words, without threading, how does commons cache any data? If I know
> how, then I will surely use this feature from commons rather than
> writing my own logic.
Commons Configuration keeps the timestamp of the last file check. On
accessing a property (by calling getString(), getInt(), etc), the file
is checked again if a specified delay is elapsed since the last check.
Of course the configuration is not reloaded after this delay if the file
didn't change.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Configuration - Reload Strategy in j2ee containers
Posted by WANG Qingtian <qi...@gmail.com>.
Soaring Eagle wrote:
>
> How does commons configuration determine when the interval is done
> without caching at least the timestamp of the last read? In other
> words, without threading, how does commons cache any data?
I am not sure.... but if you have a Singleton that has a field storing
the last systime the reload was done, when the "getXXX()" is called, it
could do something like
if (currentSystime - this.lastTimeReload > setInterval) {
reload();
return somethingNewlyCached;
} else {
return somethingAlreadyCached;
}
Again since I didn't look at the code, I am just guessing out of
nowhere.... :)
> If I know
> how, then I will surely use this feature from commons rather than
> writing my own logic.
>
> I use eclipse to start or stop my container. I will surely test all
> this with other means. I doubt though that this will be a major issue.
Appreciate it if you'd let me know how that turns out and the specific
container you use when all this happens.
Thanks!
Qingtian
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Configuration - Reload Strategy in j2ee containers
Posted by Soaring Eagle <co...@gmail.com>.
> I also asked the performance question. What he said was that you can set
> the reload interval programmatically via the Configuration API itself,
> which will cause the reload to happen only when the interval set is due.
> That effectively does the same thing as with the monitoring thread. I
> didn't look into the code and see if the config data are cached in
> between the same interval. But I'd imagine it'd do the caching....
How does commons configuration determine when the interval is done
without caching at least the timestamp of the last read? In other
words, without threading, how does commons cache any data? If I know
how, then I will surely use this feature from commons rather than
writing my own logic.
> Did you try really shutdown the container from the command line in the
> real case scenario other than the unit test, and see if the custom
> thread being killed? If so, great. But I am not sure that behavior
> guaranteed for various containers, though. It's interesting. Please let
> me how you find out.
I use eclipse to start or stop my container. I will surely test all
this with other means. I doubt though that this will be a major issue.
On Apr 6, 2005 3:44 PM, WANG Qingtian <qi...@gmail.com> wrote:
> Soaring Eagle wrote:
> >>Since the container doesn't have the control over the life cycle of the
> >>thread that takes care of the reload, say next time the container
> >>starts, you don't want the reloading to take effect not all, you'd have
> >>to figure out a way to kill that thread....?
> >
> >
> > In my unit tests, when I request the container to shutdown, my custom
> > thread also shuts down.
>
> Did you try really shutdown the container from the command line in the
> real case scenario other than the unit test, and see if the custom
> thread being killed? If so, great. But I am not sure that behavior
> guaranteed for various containers, though. It's interesting. Please let
> me how you find out.
>
>
> >
> >
> >>Plus per the email Emmanuel sent, commons-configuration seems already to
> >>have a built-in mechanism to do the periodical reload without spawning
> >>any thread....
> >
> >
> > If I understood that email correctly, the reload strategy basically
> > loads the configuration file each time any configuration is asked for.
> > That is great - however, for various reasons (mainly small performance
> > gains), I prefer to load configuration through a singleton class -
> > effectively caching all configuration. when applications require
> > config data, they get it from the in memory singleton cache. A
> > background thread of this singleton class checks for changes at
> > regular intervals and refreshes the in-memory configuration.
>
> I also asked the performance question. What he said was that you can set
> the reload interval programmatically via the Configuration API itself,
> which will cause the reload to happen only when the interval set is due.
> That effectively does the same thing as with the monitoring thread. I
> didn't look into the code and see if the config data are cached in
> between the same interval. But I'd imagine it'd do the caching....
>
>
> >
> > On Apr 6, 2005 2:57 PM, WANG Qingtian <qi...@gmail.com> wrote:
> >
> >>Soaring Eagle wrote:
> >>
> >>>Hello all,
> >>>
> >>>In an app we are doing, we use commons config to load properties and
> >>>use a threaded class to do the reload every few seconds. this is then
> >>>packaged as a part of a j2ee application. When application code is
> >>>referenced for the first time, a thread is started and this thread
> >>>checks for modifications at intervals. Though the J2EE spec does not
> >>>allow a developer to start threads, this seems to work well for me.
> >>
> >>Since the container doesn't have the control over the life cycle of the
> >>thread that takes care of the reload, say next time the container
> >>starts, you don't want the reloading to take effect not all, you'd have
> >>to figure out a way to kill that thread....?
> >>
> >>Plus per the email Emmanuel sent, commons-configuration seems already to
> >>have a built-in mechanism to do the periodical reload without spawning
> >>any thread....
> >>
> >>
> >>
> >>>The other option would be create a java application class as the
> >>>configuration wrapper (containing a main method) and to start that
> >>>class as a "startup" class in the J2EE container.
> >>
> >>That'll work until the time comes when you want switch to a container
> >>that doesn't offer a startup/shutdown class. Once in a blue moon you'd
> >>want to switch containers, but still....
> >>
> >>
> >>
> >>>Please share your views on this type of design.
> >>>
> >>>Thanks
> >>>Eagle.
> >>>
> >>>On Apr 4, 2005 5:47 PM, WANG Qingtian <qi...@gmail.com> wrote:
> >>>
> >>>
> >>>>Hi,
> >>>>
> >>>>Is the reload strategy implemented by creating a thread that
> >>>>periodically checks the time stamp of the configuration file? If so, how
> >>>>do I make sure that thread is started/stopped properly when I use it in
> >>>>a j2ee container? Like, will the thread be killed when I shut down the
> >>>>web/ejb container? What is the "best practice" of using "configuration"
> >>>>in a j2ee container?
> >>>>
> >>>>Thanks a lot for your help!!!
> >>>>Qingtian
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> >>>>For additional commands, e-mail: commons-user-help@jakarta.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail: commons-user-help@jakarta.apache.org
> >>>
> >>>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: commons-user-help@jakarta.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Configuration - Reload Strategy in j2ee containers
Posted by WANG Qingtian <qi...@gmail.com>.
Soaring Eagle wrote:
>>Since the container doesn't have the control over the life cycle of the
>>thread that takes care of the reload, say next time the container
>>starts, you don't want the reloading to take effect not all, you'd have
>>to figure out a way to kill that thread....?
>
>
> In my unit tests, when I request the container to shutdown, my custom
> thread also shuts down.
Did you try really shutdown the container from the command line in the
real case scenario other than the unit test, and see if the custom
thread being killed? If so, great. But I am not sure that behavior
guaranteed for various containers, though. It's interesting. Please let
me how you find out.
>
>
>>Plus per the email Emmanuel sent, commons-configuration seems already to
>>have a built-in mechanism to do the periodical reload without spawning
>>any thread....
>
>
> If I understood that email correctly, the reload strategy basically
> loads the configuration file each time any configuration is asked for.
> That is great - however, for various reasons (mainly small performance
> gains), I prefer to load configuration through a singleton class -
> effectively caching all configuration. when applications require
> config data, they get it from the in memory singleton cache. A
> background thread of this singleton class checks for changes at
> regular intervals and refreshes the in-memory configuration.
I also asked the performance question. What he said was that you can set
the reload interval programmatically via the Configuration API itself,
which will cause the reload to happen only when the interval set is due.
That effectively does the same thing as with the monitoring thread. I
didn't look into the code and see if the config data are cached in
between the same interval. But I'd imagine it'd do the caching....
>
> On Apr 6, 2005 2:57 PM, WANG Qingtian <qi...@gmail.com> wrote:
>
>>Soaring Eagle wrote:
>>
>>>Hello all,
>>>
>>>In an app we are doing, we use commons config to load properties and
>>>use a threaded class to do the reload every few seconds. this is then
>>>packaged as a part of a j2ee application. When application code is
>>>referenced for the first time, a thread is started and this thread
>>>checks for modifications at intervals. Though the J2EE spec does not
>>>allow a developer to start threads, this seems to work well for me.
>>
>>Since the container doesn't have the control over the life cycle of the
>>thread that takes care of the reload, say next time the container
>>starts, you don't want the reloading to take effect not all, you'd have
>>to figure out a way to kill that thread....?
>>
>>Plus per the email Emmanuel sent, commons-configuration seems already to
>>have a built-in mechanism to do the periodical reload without spawning
>>any thread....
>>
>>
>>
>>>The other option would be create a java application class as the
>>>configuration wrapper (containing a main method) and to start that
>>>class as a "startup" class in the J2EE container.
>>
>>That'll work until the time comes when you want switch to a container
>>that doesn't offer a startup/shutdown class. Once in a blue moon you'd
>>want to switch containers, but still....
>>
>>
>>
>>>Please share your views on this type of design.
>>>
>>>Thanks
>>>Eagle.
>>>
>>>On Apr 4, 2005 5:47 PM, WANG Qingtian <qi...@gmail.com> wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>Is the reload strategy implemented by creating a thread that
>>>>periodically checks the time stamp of the configuration file? If so, how
>>>>do I make sure that thread is started/stopped properly when I use it in
>>>>a j2ee container? Like, will the thread be killed when I shut down the
>>>>web/ejb container? What is the "best practice" of using "configuration"
>>>>in a j2ee container?
>>>>
>>>>Thanks a lot for your help!!!
>>>>Qingtian
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>>>
>>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Configuration - Reload Strategy in j2ee containers
Posted by Soaring Eagle <co...@gmail.com>.
> Since the container doesn't have the control over the life cycle of the
> thread that takes care of the reload, say next time the container
> starts, you don't want the reloading to take effect not all, you'd have
> to figure out a way to kill that thread....?
In my unit tests, when I request the container to shutdown, my custom
thread also shuts down.
> Plus per the email Emmanuel sent, commons-configuration seems already to
> have a built-in mechanism to do the periodical reload without spawning
> any thread....
If I understood that email correctly, the reload strategy basically
loads the configuration file each time any configuration is asked for.
That is great - however, for various reasons (mainly small performance
gains), I prefer to load configuration through a singleton class -
effectively caching all configuration. when applications require
config data, they get it from the in memory singleton cache. A
background thread of this singleton class checks for changes at
regular intervals and refreshes the in-memory configuration.
On Apr 6, 2005 2:57 PM, WANG Qingtian <qi...@gmail.com> wrote:
> Soaring Eagle wrote:
> > Hello all,
> >
> > In an app we are doing, we use commons config to load properties and
> > use a threaded class to do the reload every few seconds. this is then
> > packaged as a part of a j2ee application. When application code is
> > referenced for the first time, a thread is started and this thread
> > checks for modifications at intervals. Though the J2EE spec does not
> > allow a developer to start threads, this seems to work well for me.
>
> Since the container doesn't have the control over the life cycle of the
> thread that takes care of the reload, say next time the container
> starts, you don't want the reloading to take effect not all, you'd have
> to figure out a way to kill that thread....?
>
> Plus per the email Emmanuel sent, commons-configuration seems already to
> have a built-in mechanism to do the periodical reload without spawning
> any thread....
>
>
> >
> > The other option would be create a java application class as the
> > configuration wrapper (containing a main method) and to start that
> > class as a "startup" class in the J2EE container.
>
> That'll work until the time comes when you want switch to a container
> that doesn't offer a startup/shutdown class. Once in a blue moon you'd
> want to switch containers, but still....
>
>
> >
> > Please share your views on this type of design.
> >
> > Thanks
> > Eagle.
> >
> > On Apr 4, 2005 5:47 PM, WANG Qingtian <qi...@gmail.com> wrote:
> >
> >>Hi,
> >>
> >>Is the reload strategy implemented by creating a thread that
> >>periodically checks the time stamp of the configuration file? If so, how
> >>do I make sure that thread is started/stopped properly when I use it in
> >>a j2ee container? Like, will the thread be killed when I shut down the
> >>web/ejb container? What is the "best practice" of using "configuration"
> >>in a j2ee container?
> >>
> >>Thanks a lot for your help!!!
> >>Qingtian
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: commons-user-help@jakarta.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Configuration - Reload Strategy in j2ee containers
Posted by WANG Qingtian <qi...@gmail.com>.
Soaring Eagle wrote:
> Hello all,
>
> In an app we are doing, we use commons config to load properties and
> use a threaded class to do the reload every few seconds. this is then
> packaged as a part of a j2ee application. When application code is
> referenced for the first time, a thread is started and this thread
> checks for modifications at intervals. Though the J2EE spec does not
> allow a developer to start threads, this seems to work well for me.
Since the container doesn't have the control over the life cycle of the
thread that takes care of the reload, say next time the container
starts, you don't want the reloading to take effect not all, you'd have
to figure out a way to kill that thread....?
Plus per the email Emmanuel sent, commons-configuration seems already to
have a built-in mechanism to do the periodical reload without spawning
any thread....
>
> The other option would be create a java application class as the
> configuration wrapper (containing a main method) and to start that
> class as a "startup" class in the J2EE container.
That'll work until the time comes when you want switch to a container
that doesn't offer a startup/shutdown class. Once in a blue moon you'd
want to switch containers, but still....
>
> Please share your views on this type of design.
>
> Thanks
> Eagle.
>
> On Apr 4, 2005 5:47 PM, WANG Qingtian <qi...@gmail.com> wrote:
>
>>Hi,
>>
>>Is the reload strategy implemented by creating a thread that
>>periodically checks the time stamp of the configuration file? If so, how
>>do I make sure that thread is started/stopped properly when I use it in
>>a j2ee container? Like, will the thread be killed when I shut down the
>>web/ejb container? What is the "best practice" of using "configuration"
>>in a j2ee container?
>>
>>Thanks a lot for your help!!!
>>Qingtian
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Configuration - Reload Strategy in j2ee containers
Posted by Soaring Eagle <co...@gmail.com>.
Hello all,
In an app we are doing, we use commons config to load properties and
use a threaded class to do the reload every few seconds. this is then
packaged as a part of a j2ee application. When application code is
referenced for the first time, a thread is started and this thread
checks for modifications at intervals. Though the J2EE spec does not
allow a developer to start threads, this seems to work well for me.
The other option would be create a java application class as the
configuration wrapper (containing a main method) and to start that
class as a "startup" class in the J2EE container.
Please share your views on this type of design.
Thanks
Eagle.
On Apr 4, 2005 5:47 PM, WANG Qingtian <qi...@gmail.com> wrote:
> Hi,
>
> Is the reload strategy implemented by creating a thread that
> periodically checks the time stamp of the configuration file? If so, how
> do I make sure that thread is started/stopped properly when I use it in
> a j2ee container? Like, will the thread be killed when I shut down the
> web/ejb container? What is the "best practice" of using "configuration"
> in a j2ee container?
>
> Thanks a lot for your help!!!
> Qingtian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Configuration - Reload Strategy in j2ee containers
Posted by WANG Qingtian <qi...@gmail.com>.
Superb. Thanks!
Emmanuel Bourg wrote:
> When the FileChangedReloadingStrategy is used the method
> reloadingRequired() is called every time a property is accessed. This
> method checks if the file has changed according to its last modified
> time (File.lastModified() is called), but it will not perform this check
> if it has already been made recently (the exact delay is set by
> setRefreshDelay). If reloadingRequired() returns true, the configuration
> is cleared and loaded again.
>
> So the performance depends on the refreshDelay and the time required to
> load the configuration, this is typically linked to the size of your file.
>
> Emmanuel Bourg
>
>
> WANG Qingtian wrote:
>
>> Hello Emmanuel,
>>
>> Thanks very much for the clarification! Can you also shed some light
>> on the performance issue when the reloading mechanism is used versus
>> when not used?
>>
>> Thanks again!
>> Qingtian
>>
>>
>>
>> Emmanuel Bourg wrote:
>>
>>> Hello Qingtian, a reloading strategy is passive, it doesn't spawn a
>>> thread to monitor the file, instead it checks if the file changed
>>> everytime a property is accessed. So just use it as a replacement for
>>> java.util.Properties.
>>>
>>> Emmanuel Bourg
>>>
>>>
>>> WANG Qingtian wrote:
>>>
>>>> Hi,
>>>>
>>>> Is the reload strategy implemented by creating a thread that
>>>> periodically checks the time stamp of the configuration file? If so,
>>>> how do I make sure that thread is started/stopped properly when I
>>>> use it in a j2ee container? Like, will the thread be killed when I
>>>> shut down the web/ejb container? What is the "best practice" of
>>>> using "configuration" in a j2ee container?
>>>>
>>>> Thanks a lot for your help!!!
>>>> Qingtian
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Configuration - Reload Strategy in j2ee containers
Posted by Emmanuel Bourg <eb...@apache.org>.
When the FileChangedReloadingStrategy is used the method
reloadingRequired() is called every time a property is accessed. This
method checks if the file has changed according to its last modified
time (File.lastModified() is called), but it will not perform this check
if it has already been made recently (the exact delay is set by
setRefreshDelay). If reloadingRequired() returns true, the configuration
is cleared and loaded again.
So the performance depends on the refreshDelay and the time required to
load the configuration, this is typically linked to the size of your
file.
Emmanuel Bourg
WANG Qingtian wrote:
> Hello Emmanuel,
>
> Thanks very much for the clarification! Can you also shed some light on
> the performance issue when the reloading mechanism is used versus when
> not used?
>
> Thanks again!
> Qingtian
>
>
>
> Emmanuel Bourg wrote:
>
>> Hello Qingtian, a reloading strategy is passive, it doesn't spawn a
>> thread to monitor the file, instead it checks if the file changed
>> everytime a property is accessed. So just use it as a replacement for
>> java.util.Properties.
>>
>> Emmanuel Bourg
>>
>>
>> WANG Qingtian wrote:
>>
>>> Hi,
>>>
>>> Is the reload strategy implemented by creating a thread that
>>> periodically checks the time stamp of the configuration file? If so,
>>> how do I make sure that thread is started/stopped properly when I use
>>> it in a j2ee container? Like, will the thread be killed when I shut
>>> down the web/ejb container? What is the "best practice" of using
>>> "configuration" in a j2ee container?
>>>
>>> Thanks a lot for your help!!!
>>> Qingtian
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Configuration - Reload Strategy in j2ee containers
Posted by WANG Qingtian <qi...@gmail.com>.
Hello Emmanuel,
Thanks very much for the clarification! Can you also shed some light on
the performance issue when the reloading mechanism is used versus when
not used?
Thanks again!
Qingtian
Emmanuel Bourg wrote:
> Hello Qingtian, a reloading strategy is passive, it doesn't spawn a
> thread to monitor the file, instead it checks if the file changed
> everytime a property is accessed. So just use it as a replacement for
> java.util.Properties.
>
> Emmanuel Bourg
>
>
> WANG Qingtian wrote:
>
>> Hi,
>>
>> Is the reload strategy implemented by creating a thread that
>> periodically checks the time stamp of the configuration file? If so,
>> how do I make sure that thread is started/stopped properly when I use
>> it in a j2ee container? Like, will the thread be killed when I shut
>> down the web/ejb container? What is the "best practice" of using
>> "configuration" in a j2ee container?
>>
>> Thanks a lot for your help!!!
>> Qingtian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Configuration - Reload Strategy in j2ee containers
Posted by Emmanuel Bourg <eb...@apache.org>.
Hello Qingtian, a reloading strategy is passive, it doesn't spawn a
thread to monitor the file, instead it checks if the file changed
everytime a property is accessed. So just use it as a replacement for
java.util.Properties.
Emmanuel Bourg
WANG Qingtian wrote:
> Hi,
>
> Is the reload strategy implemented by creating a thread that
> periodically checks the time stamp of the configuration file? If so, how
> do I make sure that thread is started/stopped properly when I use it in
> a j2ee container? Like, will the thread be killed when I shut down the
> web/ejb container? What is the "best practice" of using "configuration"
> in a j2ee container?
>
> Thanks a lot for your help!!!
> Qingtian
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org