#539: Product-scope TracAdmin commands don't take effect until tracd is
restarted
------------------------+-------------------------------
Reporter: rjollos | Owner: rjollos
Type: defect | Status: review
Priority: major | Milestone: Release 8
Component: dashboard | Version:
Resolution: | Keywords: tracadmin command
------------------------+-------------------------------
Comment (by olemis):
I just remembered now what were these patches all about . Once upon a time
I just submitted the code to synchronize product config files, which was a
subtle feature request considering comment:4 .
Like I just said in comment:13 components on/off status is influenced by
two levels of cache stored in environment's `enabled` and `_rules`
attributes. The goal of
[attachment:t539_r1545950_product_component_dyn_status.diff attached
patch] is to watch for modification time of product env's config lock file
(introduced in previous patches ;) . If values loaded in memory are
outdated then firstly product env's config is reloaded. Cached data
influencing component state is cleared as well.
It is a fact that components will be enabled in product context only if
they are enabled in the global environment as well. Therefore cache
invalidation takes place for both product and global env. In its current
form this approach may be inefficient (and there's an inline FIXME tag in
for this ;) e.g. in a global env having n products with updated config
values then even if global config does not change at all its cache will
invalidated O(n) times . This means that global [components] section will
be (systematicly and unnecessarily) reloaded every time a configuration
value is added in a product. This might lead to serious performance
penalties and overhead, but works as expected. @rjollos : since this
belongs in our Trac copy and maight be backported to Trac then I thought
I'd rather delegate such improvements for you to move forward with this
ticket if you do not mind , otherwise let me know and I'll focus on a new
patch.
Ideally cache invalidation should work like this
||= Global config =||= Product config =||= Global on/off cache =||=
Product on/off cache =||
|| outdated || unchanged || invalidate (clear) ||
invalidate (clear) ||
|| outdated || outdated || invalidate (clear) ||
invalidate (clear) ||
|| unchanged || outdated || keep in-memory copy ||
invalidate (clear) ||
|| unchanged || unchanged || keep in-memory copy || keep
in-memory copy ||
... and another potentially useful optimization may consist in computing a
diff upon [components] section (rather than whole config modification
time) to decide whether cached on/off data have to be cleared or not .
This may be overkill though
The [http://pastebin.com/urQsMENh test report] illustrates that there are
no regressions . Details follow
{{{#!sh
$ hg qapplied
t539/t539_r1516428_test_product_config_sync.diff
t539/t539_r1516428_product_config_sync.diff
t539/t539_r1516428_test_product_config_sync.2.diff
t539/t539_r1545950_product_component_dyn_status.diff
$ hg log -r qparent
changeset: 497:e260cdce0b83
tag: qparent
tag: svn-1545950
user: rjollos@13f79535-47bb-0310-9956-ffa450edef68
date: Wed Nov 27 07:21:58 2013 +0000
summary: 0.8dev: Integrate change from [trac 12268].
}}}
PS: There are a number of adjustments in test code to consider values not
formerly written in environment stub's config at testing time .
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/539#comment:14>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound issue tracker
