costin 2002/12/11 10:37:56
Modified: jk/xdocs/jk2 configweb.xml
Log:
Added a section on runtime reconfiguration.
Revision Changes Path
1.13 +37 -1 jakarta-tomcat-connectors/jk/xdocs/jk2/configweb.xml
Index: configweb.xml
===================================================================
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk2/configweb.xml,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- configweb.xml 3 Oct 2002 15:34:10 -0000 1.12
+++ configweb.xml 11 Dec 2002 18:37:56 -0000 1.13
@@ -38,4 +38,40 @@
</source>
</p>
</section>
+
+ <section name="Advanced: reconfiguration">
+ <p>One of the features ok jk2 is support for (partial) reconfiguration at
runtime, without a restart. The main
+use is to add/remove/change workers and uris. This allows smooth updates, without
server restarts, where each
+worker is upgraded while the other workers server content. </p>
+
+<p>The jk2 architecture is modeled after JMX, and in future it'll have a JMX proxy
that will make most
+reconfiguration transparent. This section describes the mechanisms used for
reconfiguration.</p>
+
+<p>Each Jk2 component has a name and a number of attributes. The config is
abstracted - but for simplicity
+we'll discuss the default ( ini-file ) format. Some of the attributes and
components support run time
+changes. The most important is "disabled", that allows a component to be included
or excluded from
+the runtime. </p>
+
+<p>The easiest way to reconfigure jk2 is by making modifications to the config
file. Jk will
+process the file again and call the setters for attributes - including disabled,
etc. Only
+components and attributes that include support for reloading will be affected.
+</p>
+
+<p>The reconfig is enabled by using a flag in the scoreboard. The flag can be set
programmatically,
+or it'll be set automatically every time the jk_status page is displayed if a
change is
+detected in the config file </p>
+
+<p>A more advanced ( and less tested ) reconfiguration mechanism uses the jk_config
API, called
+programmatically using messages from server or using jk_status web interfaces.
Every time
+a change is made, the config file will be written ( for persistence and to allow
other processes to
+get the same change ). The scoreboard will be changed, and then all other server
processes will
+act just like in the case of a file change.</p>
+
+<p>A typical user will just edit the config file, add more workers or URIs or
change disabled flag
+of existing workers/uris. Then it'll access the jk_status page, which will detect
the config
+file changes and reload the config in the current server process, and use the
scoreboard to
+inform other server processes of the change. </p>
+
+
+
</document>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
