Mailing List Archive

#3833: Automatic reload of configuration and plugins
----------------------------+-----------------------------------------------
Reporter: trac@yadan.net | Owner: jonas
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: general | Version: 0.10
Severity: normal | Resolution:
Keywords: |
----------------------------+-----------------------------------------------
Comment (by eblot):

Checking a timestamp is fast (to detect a file change) but how to use the
new version of the file without restarting the server?

--
Ticket URL: <http://trac.edgewall.org/ticket/3833#comment:1>
The Trac Project <http://trac.edgewall.org/>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Tickets" group.
To post to this group, send email to trac-tickets@googlegroups.com
To unsubscribe from this group, send email to trac-tickets-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.se/group/trac-tickets
-~----------~----~----~----~------~----~------~--~---

#3833: Automatic reload of configuration and plugins
----------------------------+-----------------------------------------------
Reporter: trac@yadan.net | Owner: jonas
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: general | Version: 0.10
Severity: normal | Resolution:
Keywords: |
----------------------------+-----------------------------------------------
Comment (by simon-code@bvnetwork.no):

Regular configuration data like banner logo, project description and so on
already works like this without restart - essentially values that operate
as pure 'settings' and are only fetched by reading the {{{env.config}}} by
the relevant module. Look at {{{_open_environment()}}} environment cache
in {{{trac.web.main}}} that checks if the trac.ini has changed, and
reloads if true. I use Apache with mod_python, and this works fine as far
as I can tell.

However, the issue of reloading plugins is something I have been wondering
about too (and are in need of). That does not work with mod_python, and I
am also interested in finding some sort of 'deep environment reset' after
changing trac.ini that also includes a full set of components.

The mentioned {{{Environment}}} cache contains a
{{{env.config.parse_if_needed()}}} that handles refresh of the config
settings, and somehow there should also be a way to reset the component
manager. One idea is having a similar call to a new function
{{{env.compmgr.reload_if_needed()}}} called after reading new settings -
having the {{{env.config.parse_if_needed()}}} return true if
{{{[components]}}} config settings are changed, or maybe setting a flag
like {{{env.compmgr.is_dirty}}} to true if the environment needs a
components refresh.

Implementing a check as an overlay to all possible plugin load
possibilities (plugin folder and so on), is not very feasible - it will
likely be a time-consuming compare operation that affects performance when
run for each and every request. However, just comparing the config
settings for {{{[components]}}} before and after refresh is a quick
operation.

As long as any plugin change is accompanied by a change in trac.ini
{{{[components]}}} section, it will trigger a reload accomplished by de-
referencing old components and loading a fresh set using
{{{trac.loader.load_components()}}}.

Would such a scenario work?

--
Ticket URL: <http://trac.edgewall.org/ticket/3833#comment:2>
The Trac Project <http://trac.edgewall.org/>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Tickets" group.
To post to this group, send email to trac-tickets@googlegroups.com
To unsubscribe from this group, send email to trac-tickets-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.se/group/trac-tickets
-~----------~----~----~----~------~----~------~--~---

#3833: Automatic reload of configuration and plugins
----------------------------+-----------------------------------------------
Reporter: trac@yadan.net | Owner: jonas
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: general | Version: 0.10
Severity: normal | Resolution:
Keywords: |
----------------------------+-----------------------------------------------
Comment (by pkou at ua.fm):

I would object deep configuration reload automatically. A configuration
can be edited by administrator and some interim changes can be saved
easily. This can lead to loading of invalid/incomplete configuration as
result.

Assuming that the project is in use by some development team, this can
lead to loosing of data easily. (Imagine if you have entered a two page
wiki or ticket, and the system crashed after pressing Preview.)

It is better to have configuration reload on demand, e.g. an administrator
should explicitly ask Trac to reload its configs.

There is a wide range of methods for doing the explicit request about
config reload, e.g.:
* Sending a signal to Trac (and have a support for this via
{{{/var/run}}} approach);
* Creating an empty file in some predefined location that is deleted by
Trac when it detects it;
* Use some IPC mechanisms for signalling the request.
Upon receiving the request, Trac can reload configs in proper time.

--
Ticket URL: <http://trac.edgewall.org/ticket/3833#comment:3>
The Trac Project <http://trac.edgewall.org/>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Tickets" group.
To post to this group, send email to trac-tickets@googlegroups.com
To unsubscribe from this group, send email to trac-tickets-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.se/group/trac-tickets
-~----------~----~----~----~------~----~------~--~---

#3833: Automatic reload of configuration and plugins
----------------------------+-----------------------------------------------
Reporter: trac@yadan.net | Owner: jonas
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: general | Version: 0.10
Severity: normal | Resolution:
Keywords: |
----------------------------+-----------------------------------------------
Comment (by simon-code@bvnetwork.no):

That isn't actually quite as things work in Trac, I think.

If you for instance don't use mod_python, but use a simple CGI setup
instead, the Environment gets completely reloaded for each request. Such a
request essentially have no history - a Python process is started, modules
loaded, Trac processing started, and when request is done the whole Python
process dies.

The reason this also works is because request specific information (like
your preview example) gets passed around as arguments to the request
object - available inside the {{{req}}} context.

This discussion is really about trying to get the best of both worlds -
the persistance and performance of mod_python, with the flexibility of
making config changes on-the-fly. Actually, config changes are currently
made on-the-fly after each file save also when using mod_python, it is
just that for {{{[components]}}} they don't have any effect.

Lastly, to clarify my previous comment: The use of of ''deep reload'' was
probably not the best words to use - it is not in the Python
{{{reload()}}} meaning. Reloading modules and class definitions is a
totally different challenge fraught with potential pitfalls... I really
mean a refresh of the component lists for the environment, but using the
already loaded Python code (or load new modules/components if first time
use).

--
Ticket URL: <http://trac.edgewall.org/ticket/3833#comment:4>
The Trac Project <http://trac.edgewall.org/>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Tickets" group.
To post to this group, send email to trac-tickets@googlegroups.com
To unsubscribe from this group, send email to trac-tickets-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.se/group/trac-tickets
-~----------~----~----~----~------~----~------~--~---