Hauptseite

IIS6 mit JK2 im IIS6-Mode

Allgemeines

Umgebungsvariablen setzen

JK2 Vorbereiten

Die Redirector-DLL ablegen

Registry-Anpassungen für den JK2

JK2-Konfigurationsfile "worker2.properties"

IIS Anpassen

Den ISAPI Redirector Filter in den IIS6 einhängen

Webdiensterweiterung erlauben

Jakarta-Verzeichnisse anlegen

JK2 Vorab-Test

Application-Pooling

Tomcat Anpassen

JK2-Konfigurationsfiles auf Tomcat-Seite

Anpassungen am Tomcat 5 "server.xml": Der IIS Authentication vertrauen

JK2 in Aktion

Test des Connectors

Laufzeit-Rekonfiguration des JK2

Fazit

Anhang A: "JK.reg"

Anhang B: "worker2.properties"

Allgemeines

Es gibt eine Menge Anleitungen, die den IIS6 mit einem Tomcat verbinden. Leider nutzt kaum eine das volle Potential der neueren Technologien aus, so dass meistens der IIS6 im IIS5-Kompatibilitätsmodus betrieben werden muss oder noch der JK1.x eingesetzt wird. Ausserdem gibt es so gut wie keine deutschen Guides.

All diese Nachteile möchte dieses HowTo umgehen, welches im Rahmen eines IIS6-JK2-Tomcat5 Proof-of-Concept entstand. Es wird der aktuelle IIS6 im vollen IIS6 (Application Pooling) -Mode eingesetzt, der JK2 mit erweiterter Konfiguration und Laufzeit-rekonfiguration getestet sowie als Backend der aktuelle Tomcat 5.0.27 angesprochen. Die Sprache ist mehr oder weniger Deutsch (IT-Deutsch).

Es wird davon ausgegangen, das der IIS6 bereits lauffähig, mit Authentifizierung, funktioniert und auch die Tomcat-Server bereits lokal problemlos laufen.

Umgebungsvariablen setzen

Es sollte nicht vergessen werden, zu Beginn die wichtigen Umgebungsvariablen in den Systemeigenschaften der Tomcat-Server zu setzen. Es geht in diesem HowTo zwar um den Frontend-Webserver, der keine Tomcat's und Java-Engine braucht, aber da es gerne und oft vergessen wird, sei es hier noch mal erwähnt. Obwohl evtl. auch auf dem Webserver der JK2 in %CATALINA_HOME%\conf oder %CATALINA_BASE%\conf defaultmässig nach der jk2.preperties sucht. Dies ist aber auch hart konfigurierbar.

JAVA_HOME

z.B.: JAVA_HOME=D:\Java\j2sdk1.4.2_05

CATALINA_HOME

z.B: CATALINA_HOME=D:\Java\Tomcat5.0.27

JK2 vorbereiten

Zuerst ist natürlich eine Version des JK2-Connectors aus dem Internet zu besorgen. Diese muss entsprechend eingerichtet werden.

Die Redirector-DLL ablegen

Da es für die JK1-Connectoren schon genug HowTo's gibt, arbeiten wir hier mit dem neuen JK2-Connector. Er kann hier heruntergeladen werden. Das hier verwendete Release ist das jk2.0.4-win32-IIS. Im \bin-Verzeichnis findet sich die Datei "isapi_redirector2.dll". Dies ist der eigentliche Filter.

• Eine Verzeichnistruktur für den JK2-Connector aufbauen. {Base} kann z.B. "<LW>:\Java\Jakarta Tomcat connector\<JK-Version>", also so etwas wie "D:\Java\Jakarta Tomcat connector\2.0.4" sein. Der JK2 kann inzwischen auch gut mir Leerzeichen im Pfad umgehen.
  • {Base}\jk2-connector
  • {Base}\jk2-connector\bin
  • {Base}\jk2-connector\conf
• Den Filter in das Verzeichnis {Base}\jk2-connector\bin kopieren
• Die "workers2.properties.sample kann als Beispiel mit in das {Base}\jk2-connector\conf - Verzeichnis gelegt werden.
• Die Trennung der Verzeichnise ist aus Sicherheitsgründen sinnvoll, da so später über das Virtuelle jakarta-Verzeichnis nie auf die Konfiguration zugegriffen werden kann.

Registry-Anpassungen für den JK2

Auf der IIS-Seite sind Anpassungen in der Registry vorzunehmen, damit der JK grundkonfiguriert wird. Diese sind im Gegensatz zu den JK1-Einstellungen nicht mehr allzu zahlreich. Nur noch ein paar Grundeinstellungen sind bekannt zu machen. Für JK2 befinden sich diese im Zweig:

HKLM\Software\Apache Software Foundation\Jakarta Isapi Redirector\2.0 (Editieren mit RegEdit)

Folgenden StringsValues werden von JK aus der Registry gelesen (lt. Source 2.0.4). Fettgedruckte Schlüssel sind Pflicht. Die Pflichtschlüssel können auch über die in Anhang A JK.reg gelistete Datei komfortabel und mit wenig Fehlerrisiko importiert werden.
Achtung: Werden Pflichtschlüssel nicht gefunden, steigt der JK2 kommentarlos aus. Kein Log, keine Meldung, ISAPI-Filter up, und nichts funktioniert! Sourcecodeauszug:

return NULL != serverRoot && NULL != workersFile;

1. extensionUri (Empfohlen : "/jakarta/isapi_redirector2.dll")
   Die Web-URI, unter der die JK-DLL zu finden ist. Meist "/jakarta/isapi_redirector2.dll".
   
2. serverRoot (Empfohlen : AJP:{Conf-Dir}, InProcess:{TC-Dir})
   Das Verzeichnis des Tomcat-Servers. Dies ist z.B. für In-Process-Mode wichtig. Dabei kommuniziert der IIS/JK-Prozess direkt über Shared Memory mit dem TomCat-Prozess. Dies ist natürlich sehr schnell. Dies ist leider für physikalisch getrennte Webserver / Servlet-Runner - nicht möglich. Ist also wie bei unserem POC kein Tomcat für den JK2 vorhanden, so muss dieser Schlüssel den Pfad zu unserem Conf-Verzeichniss enthalten. Ist Webserver und Tomcat auf einem Server, so muss das Tomcat-Verzeichniss gleich der Conf-Verzeichniss sein. Dies ist auch vorteilhaft, da der Tomcat per Kommandozeile automatisch ein workers2.properties dort erzeugen kann, das alle Ihm bekannten Applikationen mapped.
   
3. workersFile (Empfohlen : "{Dir-to?}\workers2.properties")
   Beim JK 2 gibt es nur noch ein Konfigurationsfile, "workers2.properties". Der Ort dieses Files ist hier anzugeben.
   
4. threadPool (Empfohlen : "0" oder veglassen)
   Dieser Key steuert anscheinend das Thread-Pooling, so dass mehrere Requests durch eine Connector-Verbindung abgehandelt werden können. Hierfür wäre es logischerweise nötig, einen Shared-Mem-Bereich zu deklarieren. Der Key hat einen Integerwert im Stringformat, also "0...254". Dies ist aber nur eine Vermutung. Beachte: If threadPool < 10 then threadPool = 0! Mapped auf Variable "use_thread_pool". Codeauszug:

   /* Do nothing if the thread pool is not used */
   if (use_thread_pool <= 0)
   return JK_OK;
   else
   workers = use_thread_pool;

   Default ist 0 = kein Thread-Pooling.

5. authComplete (Empfohlen : "0" oder weglassen)
   "... which toggles authentication handled by tomcat or iis..."
   Hier scheint es sich um einen Binärwert zu handeln, (0|1), der 1 sein muss, wenn der Tomcat komplett die Authentifizierung übernehmen soll. Hierbei scheint der JK2-Filter auch als Auth-Filer zu fungieren. Wahrscheinlich fragt der JK2 den Tom mit dem vom IIS empfangenen Usernamen "Auth?", und der Tom verifiziert gegen seine Userdatenquellen. Dies ist aber nur eine Vermutung. Diese Property mapped auf die Variable "use_auth_notification_flags". Codeauszug:

   if (use_auth_notification_flags && maj > 4)
   rv = SF_NOTIFY_AUTH_COMPLETE;

   Default ist 0=JK Spielt nicht Auth-Filter.

6. sendGroups (Empfohlen : "0" oder weglassen)
   "..the sendGroups fix to avoid querying Windows for users group lists, which is important for usability in a large site...".
   Dieser Schalter soll also das nachfragen nach Gruppenzugehörigkeiten steuern. Es ist nicht klar ob auf JK- oder Tomcat-Seite und die Syntax ebensowenig. Wahrscheinlich ist dies ein Binärschalter (0|1) im Stringformat. 0=aus, 1=an. Diese Property mapped auf die Variable "send_groups". Codeauszug:

   if (send_groups && *s->remote_user) {
   char *groups = jk2_service_iis_get_roles(env, s);

   Default ist 0=Groups-Querying ist abgeschaltet.

Es sind also mit RegEdit mindestens die Keys 1-3 anzulegen und mit sinnvollen Werten zu füllen. Bei dem JK1 wurde oft mit gepatchten DLL's gearbeitet, um die Connectoren per Web in der Registry zu trennen. Allerdings ist das beim JK2 Dank des VHosts-Konzeptes zur Trennung per Web nicht mehr erforderlich.

JK2-Konfigurationsfile "worker2.properties"

Auf der Webserverseite wird für den JK2 nur noch das Konfigurationsfile "workers2.properties" benötigt. Es ist empfehlenswert, dieses aus Sicherheitsgründen nicht unterhalb des Bin-DLL-Verzeichnisses abzulegen - parallele BIN- und CONF-Verzeichnisse sind hier ratsam. Die komplette Syntaxbeschreibung findet sich unter JK2-Sytax in Internet und die Komponentenbeschreibung dieser Konfigurationsdatei unter
JK2-Komponentenbeschreibung in Internet. Generell ist das Config-File in Sektionen aufgeteilt. Einige wichtige Änderungen (für unsere Konfiguration) gegenüber JK1 sind, das der JK2 eine eigene HTML-Statusseite hat, sich zur Laufzeit umkonfigurieren lässt, ein verschlüsseltes Protokoll zu den Tomcat's beherrscht und mit kompletten HOST-Mappings ein VHOSTS-Konzept beherrscht. Letzteres wurde aber auch schon in den späten Versionen des JK1 eingeführt.
In der Konfiguration der Worker kann zwischen Workern und channels, über die mit diesen kommuniziert wird, unterschieden werden. Ausserdem kann jede Komponente, z.B. jeder VHOST, ein eigenes Log bekommen und stellt einen Tree im JMX dar.
Eine Beispielkonfiguration findet sich im Anhang B: "worker2.properties".

Einige Hinweise zum worker2.properties:

• Worker- und Channelkonfigurationen sind verwirrend. Wird ein channel.socket erzeugt, erzeugt dies implizit einen AJP13-Worker. Ein AJP13-Worker erzeugt allerdings keinen Channel.Fast alle AJP13-Konfigurationen können auch im channel.socket angegeben werden und werden dann "nach oben" vererbt. Ausnahmen bilden hier nur die folgenden Parameter:

  max_connections= {Default=0}
  connectTimeout= {Default=0}
  replyTimeout= {Default=0}
  prepostTimeout= {Default=0}

  Somit reicht es meist, die channel.socket-Konfiguration durchzuführen.

• Beim Loadbalancing-Faktor ist zu beachten, dass der Wert wesentlich geringer ist als die Anzahl der zu erwartenden Sessions. Ansonsten verzerrt sich das Balancing-Verhalten drastisch. Werden z.B. 100 Sessions erzeugt, und 4 Worker haben jeweils den "lb_factor=100", so erhält der erste Worker doppelt so viele Sessions wie die anderen 3. Ist z.B. der "lb_factor=5000"bei allen Workern, so bekommt nur der erste Worker Arbeit. Dies mag sich bei einem stetigen Sessionauf- und abbau relativieren, bei einem plötzlichen Stresstest jedoch ergaben sich diese Werte. Ein LB-Wert zwischen 1 und 10 ist hier am ehesten angebracht. Damit sollte sich annähernd jede Gewichtung abbilden lassen.
  
• Debugging ist ebenfalls sehr undurchsichtig. Jeder Bereich kann eine Debug-Angabe haben. Was wann in welches Log, und vor allem wie viel, geloggt wird, ist aber selten auf den ersten Blick ersichtlich. Hier ist wohl ausprobieren der Weg zum Ziel. Am Anfang wurden mehrere Logger konfiguriert in der Hoffnung, Worker und einzelne URI-Mappings getrennt loggen zu können. Dies funktionierte jedoch nicht wie erwartet und es wurde wieder auf ein Logfile zurückgeschaltet.
  
• Die context-property in den URI-Mappings (z.B. "context=/jsp-examples") sollte nicht gesetzt werden. Die Funktion des Filters wird eh in der Kopfzeile des URI-Mappings abgedeckt. Es ist nicht klar, weshalb; aber immer, wenn ein "context" für ein Mapping gesetzt wurde, lief der ganze JK2 nicht mehr.
  
• Wird oder soll in Zukunft per JMX konfiguriert (werden), so ist zu beachten, das JMX bei jeder Rekonfiguration das workers2.properties neu schreibt. Somit sollte das File nicht mehr bearbeitet werden. Ausserden werden alle Kommentare gelöscht. Daher ist es angebracht, gleich auf Kommentare mit "#" zu verzichten und statt dessen "info=blah..." properties einzuführen, die von JMX mitgepflegt werden können. Auch sollten Komponenten, die kurzzeitig deaktivert werden sollen, per "disabled=1" deaktiviert werden, da sie beim Auskommentieren auch gelöscht würden.

IIS Anpassen

Nun muss der ISAPI-Filter in den IIS integriert und mit den benötigten Web's verknüpft werden.

Den ISAPI Redirector Filter in den IIS6 einhängen

Der IIS muss nun den ISAPI-Filter JK2 einbinden. Dies geschieht in 3 Schritten in der IIS-Management Konsole. Es wird auch ein Install-Script "install4iis.js" in JavaScript mitgeliefert, welches in unserer Konfiguration allerdings nicht funktionierte und eher wichtige Einstellungen verstellte - wenn man es denn überhaupt zum Laufen bekommt. Dies mag in zukünftigen Versionen behoben sein, für den Moment und für die Administratoren, die gern wissen, was wie auf Ihren Systemen läuft, sei hier der manuelle Weg skizziert.

Zuerst wird in den globalen Eigenschaften der Websites der ISAPI-Filter eingebunden. Hier wird zum zuvor abgelegten DLL-File navigiert. Der Name ist beliebig, sollte aber sprechend sein.

Webdiensterweiterung erlauben

Dann wird in den "Webdiensteerweiterungen" eine neue Erweiterung hinzugefügt, die die DLL enthält und diese erlaubt. Das neue Sicherheitskonzept im IIS6 würde sonst die Ausführung dieser Datei verhindern und nichts würde funktionieren - noch nicht mal Fehlermeldungen.

Damit sind die globalen Vorbereitungen abgeschlossen.

Jakarta-Verzeichnisse anlegen

Nun werden die "Per-Web"-Einstellungen vorgenommen. In jedem Web, das Weiterleitungen für die Tomcat's enthalten soll, ist ein virtuelles Verzeichnis mit dem Namen "jakarta" anzulegen. Dieses muss auf das BIN-Verzeichnis des JK2-Connectors zeigen (z.B. D:\Java\Jakarta Tomcat connector\2.0.4\bin). Diesem Verzeichniss sind schon beim Anlegen "execute", also Ausführen-Rechte zu gewähren.

Ist dieses Verzeichnis einmal angelegt, so bietet es sich bime IIS6 an, das Verzeichnis als XML zu exportieren. In allen folgenden Web's, die JK2-Mapping benötigen, kann man es dann einfach und fehlerfrei aus dem XML importieren.

JK2 Vorab-Test

Nachdem diese und die vorangegangenen Registry-Änderungen durchgeführt sind, kann der Filter getestet werden. Es ist zu beachten, das das File workers2.properties an dem angegebenen Platz existieren muss. Es kann noch leer sein. es geht erst einmal um einen Test, ob der JK2 überhaupt im IIS6 funktioniert. Dazu ist der IIS-Admin-Service zu restarten. Danach der 1. check des globalen ISAPI-Filters. Dieser sollte noch die Priorität "unbekannt" haben. Wenn er rot ist sind die Registryeinstellungen und das Applikations-Eventlog zu prüfen.

Dann, was gern vergessen wird, ist eine Site auf dem Server mit dem Browser aufzurufen, damit der Filter überhaupt das erste mal angesprochen wird. Danach wieder den selben check des ISAPI-Filters. Nun sollte die Priorität auf "hoch" gesetzt und der Status weiterhin grün sein. Wenn nicht, wieder Registry und Eventlog-check.

Einige Administratoren ziehen es vor, den Filter nicht global sondern per Web einzubinden. Hierbei hat man einen leichen Geschwindigkeitsgewinn bei den Nicht-Java-Web's. Allerdings ist auch der Administrationsaufwand und die Wahrscheinlichkeit zur Fehlkonfiguration höher.

Application-Pooling

Es können nun neue Application-Pool's für die Websites angelegt werden. Es ist zu beachten, das die Statusinformationen, die der JK2 über seinen geteilten Speicherbereich bekannt macht, immer nur pro Application-Pool geteilt werden. Somit können sich JK2-Connectoren in unterschiedlichen Anwendungspools nicht sehen. Daher wird hier entschieden, für alle Java-Webs und Connectoren einen einzigen Pool einzurichten. Andere, z.B. unternehmenskritische ASP-Anwendungen, könen dann einen anderen Pool bekommen u.s.w. Es könnten aber auch andere Konfigurationen sinnvoller sein, wie z.B. die JavaWebs mit unterschiedlichen Pools zu belegen und lediglich die "jakarta"-Virtuellen Verzeichnisse -in den selben Pool zu legen. Um die einzelnen Applikationen mit Pools oder berechtigungen zu versehen, sind "blinde" Verzeichnisse oder Files zu erstellen. Aber all dies bedeutet auch mehr Administrationsaufwand. Deshalb wird hier der stabile, einfache Weg mit einem Pool für alle Java-Applikationen gewählt.

• Pool anlegen Name : "Java Webs und Connectoren"
• Wenn möglich bestehenden als Default wählen
• Sonst Anpassungen vornehmen:
  • "Recycle Worker Process" aus
  • Preformance -> "Idle Timeout" abschalten
  • Preformance -> "Reques queue Limit" abschalten
  • Health -> "Enable Pinging" aus
  • Health -> Enable rapid fail protection" aus
  • Identity "Nertwork Service"

Daraufhin müssen die Java-Web's dem neuen Pool hinzugefügt werden. Die virtuellen "jakarta"-Verzeichnisse sollten diese Einstellung automatisch erben.

Tomcat Anpassen

JK2-Konfigurationsfiles auf Tomcat-Seite

Auf Tomcat-Seite taucht mit Tomcat 5 das config-file "${catalina.base}/conf/jk2.properties" auf.
Laut Dokumentation wird diese Datei unter anderem vom "mod_jk2" verwendet, somit konfiguriert es die Tomcatseitige Gegenstelle des JK2. Das Tomcat-Setup funktioniert auch ohne Anpassungen in diesem File - Selbst wenn 2 Instanzen Tomcat auf dem selben Server auf unterschiedlichen Ports laufen. Soll jedoch JMX auf dem JK2 konfiguriert werden, evtl. noch mit JMX-Konfiguration des Webserverseitigen JK2-ISAPI-Filters oder ist ganz allgemein die Defaultkonfiguration nicht gewünscht, so sollte man das File entsprechend der Dokumentation anpassen.

Anpassungen am Tomcat 5 "server.xml": Der IIS Authentication vertrauen

Bei Tomcat5 und Tomcat 4.1.29+ ist das AJP13-Protokoll um Authentifizierungsoptionen erweitert worden. Das Protokoll kann (oder soll in Zukunft) mit einem Login und PW und/oder verschlüsselt erfolgen. Hierzu ist ein User auf Webserver und Servlet-Runner-Seite nötig. Solange dies nicht richtig konfiguriert (und z.T. auch noch nicht richtig implementiert) ist, führt ein misslungener Auth-Versuch auf Protokollebene dazu, das u.a. der Remote-User vom IIS gedropped wird. Um dies vorerst zu umgehen, sollte die Protokoll-Auth abgeschaltet werden. Dies geschieht in der Server.xml in der Konfiguration des AJP-Connectors.
Dazu ist folgender Parameter hinzuzufügen:

<!-- Define a Coyote/JK2 AJP 1.3 Connector on port 9009 -->
<Connector port="9009"
...
tomcatAuthentication="false"
...

In Zukunft, wenn die Protokollabsicherung stabil funktioniert, sollte aus Sicherheitsgründen das Protokoll wie vorgesehen nach Möglichkeit geschützt werden.

JK2 in Aktion

Test des Connectors

Erst an dieser Stelle sollte der erste Test erfolgen, da nun eine Verbingung mit dem Tomcat funktionieren sollte. Ein tomcat-enabled Web sollte angesprochen und die Testseiten "snoop" und "SessionExample" aufgerufen werden.

• Snoop, z.B.
  http://web1.wwwpoc.home/jsp-examples/snp/snoop.jsp
  liefert viele globale Informationen, die der Java-Applikation zur Verfügung stehen. Hier kann gut die Übergabe der Authentifizierungsinformation ausgetestet werden.
  
• SessionExample, z.B.
  http://web1.wwwpoc.home/servlets-examples/servlet/SessionExample
  ermöglicht einen guten Test der Sticky-Session-Funktionalität. Werden auch nach vielen gleichzeitigen Requests die Sessiondaten gehalten, funktioniert die JVM-Route zu den Tomcat's.

Laufzeit-Rekonfiguration des JK2

Der JK2-ISAPI-Connector kann zur Laufzeit, also ohne das Web oder den Service zu restarten, umkonfiguriert werden. Dies kann einerseits direkt über eine Änderung im "workers2.properties" geschehen oder über JMX. Die JMX-Variante ist in einem anderen Dokument hinreichend beschrieben. Hier soll die Vorgehensweise bei der direkten Änderung dargelegt werden. Der JK2-Connector überprüft das File "workers2.properties" auf Änderungen anhand des Änderungsdatums. Damit dies nicht andauernd geschehen muss und Leistung kostet, passiert dies nur, wenn die Statuspage "/jkstatus" angesprochen wird.

Innerhalb der Datei gibt es einzelne Abschnitte, die unter anderem immer ein einheitliches Attribut enthalten können: "ver" für Version. Es ist mit einem LongInt-Wert belegt. Wird das File als verändert erkannt, prüft der JK2, ob in einer Sektion das "ver"-Attribut erhöht wurde. Wenn ja, liesst er diesen Konfigurationsteil neu und teilt die Änderung über den SHM-Bereich des anderen JK2-Thread's mit.

Alle Einstellungen funktionieren wahrscheinlich noch nicht dynamisch. Aber das ist auch nicht notwendig. Laufzeit-Rekonfiguration wurde entworfen, um in Hochverfügbarkeitssystemen Tomcat-Worker hinzufügen, zu entfernen, neu zu gewichten und ähnliches durchzuführen - Ohne dass auch nur eine Session durch harte Neustarts verloren geht.

Hierzu wurde unter anderem das "graceful"-Attribut für die channels eingeführt. Wird ein Channel auf "graceful=1" gesetzt, so nimmt er keine neuen Anfragen mehr an, nur bestehende Sticky-Session-Routings werden noch zu Ihm geleitet. Dies hat den Effekt, dass die Clusternode analog zum WLBS-Clustering "gedrained" wird, also langsam leerfliesst. Sind schliesslich keine Sessions mehr auf der Node, kann man sie disablen und Wartungsarbeiten durchführen..

Fazit

Es ist seltsam, dass so wenig gute Guides zu den wirklich bemerkenswert besseren Techniken der letzten Monate und teilweise Jahre existieren. Die meisten HowTo's verwenden den JK1, IIS5-Compat-Mode oder sogar Registry-Hack's, um IIS und Tomcat zu flüssiger Verständigung zu überreden. Dabei hat sich an allen Fronten viel getan, und die oben beschriebene Konfiguration läuft sehr stabil, ist leicht administrierbar und zukunftssicherer.

Anhang A: "JK.reg"

Diese Zeilen können in eine Datei "jk.reg" eingefügt werden.
Der Token {Conf-Dir} muss noch den lokalen Gegebenheiten angepasst werden, z.B. "D:\Java\Jakarta Tomcat connector\2.0.4\conf". Dann kann man die Datei einfach der Registry hinzufügen. Hiermit sind die 3 Pflichtschlüssel behandelt, nicht jedoch alle 6 möglichen Schlüssel. Die Konfiguration sollte allerdings so weit als möglich im Conf-File erfolgen.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation]

[HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Jakarta Isapi Redirector]

[HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Jakarta Isapi Redirector\2.0]
"extensionUri"="/jakarta/isapi_redirector2.dll"
"serverRoot"="{Conf-Dir}"
"workersFile"="{Conf-Dir}\\workers2.properties"

Anhang B: "worker2.properties"

Die Dokumentation der Einstellungen findet sich hier. Es ist zu beachten, das Kommentare wie hier nur sinnvoll sind, wenn die Datei direkt bearbeitet wird. Wird dagegen mit JMX die JK2-Konfiguration manipuliert, so verschwinden sowieso alle Kommentare beim ersten Update und die Datei wird reorganisiert. In dem Fall sollten alle Kommentare in die "info="-Felder wandern, wie es hier auch schon demonstriert ist.

Nach einem Update ist das "ver="-Feld zu erhöhen. Es hat das "long"-Format und kann somit auch Timestamps aufnehmen, was z.B. bei einer programmtechnischen Generierung dieser Datei viel Sinn macht.

# -----------------------------------------------------------
# Globale Re-Konfiguration
# -----------------------------------------------------------
[config:]
file=D:\Java\Jakarta Tomcat connector\2.0.4\conf\workers2.properties
info=Defined in mod_jk2.conf. Config-Reconfiguration ?!
ver=2
debug=info
debugEnv=0

# -----------------------------------------------------------
# Shared-Memory Bereich
# -----------------------------------------------------------
[shm:]
info=Shared Memory fuer Scoreboard (statuspage) und reconfiguration. anon ^= mem
ver=200480501124
file=anonymous

# -----------------------------------------------------------
# Globale Parameter
# -----------------------------------------------------------
[workerEnv:]
info=Global server options.
ver=200480501124
sslEnable=0
timing=0
debug=info
logger=logger.file:default

# -----------------------------------------------------------
# Logger-Konfiguration
# -----------------------------------------------------------
[logger.file:default]
info=Konfiguration des unter workerEnv angegebenen logs fuer JK2
ver=200480501124
file=D:\Logfiles\jk2.log
level=info

# Testlogger, abgeschaltet
[logger.file:test]
info=Ein anderes Filelog (Debug-Mode), abgeschaltet
ver=200480501124
file=D:\Logfiles\jk2_test.log
level=debug
disabled=1

# -----------------------------------------------------------
# Channel-Konfiguration
# -----------------------------------------------------------
[channel.socket:172.17.68.7:8009]
info=Worker Channel 1
ver=200480501130
debug=info
port=8009
host=172.17.68.7
timeout=60
lb_factor=5
level=1
group=loadbalancer
tomcatId=POCTC1_I1
graceful=0
disabled=0

[channel.socket:172.17.68.7:9009]
info=Worker Channel 2
ver=200480501130
debug=info
port=9009
host=172.17.68.7
timeout=60
lb_factor=5
level=1
group=loadbalancer
tomcatId=POCTC1_I2
graceful=0
disabled=0

[channel.socket:172.17.68.8:8009]
info=Worker Channel 3
ver=200480501124
debug=info
port=8009
host=172.17.68.8
timeout=60
lb_factor=5
level=1
group=loadbalancer
tomcatId=POCTC2_I1
graceful=0

[channel.socket:172.17.68.8:9009]
info=Worker Channel 4
ver=200480501124
debug=info
port=9009
host=172.17.68.8
timeout=60
lb_factor=5
level=1
group=loadbalancer
tomcatId=POCTC2_I2
graceful=0

# -----------------------------------------------------------
# Worker-Konfiguration
# -----------------------------------------------------------
[ajp13:172.17.68.7:8009]
info=Worker 1 fuer Channel 1. max_connections and timeouts=0 ^= no limit
ver=200480501133
channel=channel.socket:172.17.68.7:8009
max_connections=0
connectTimeout=0
replyTimeout=0
prepostTimeout=0

[ajp13:172.17.68.7:9009]
info=Worker 2 fuer Channel 2. max_connections and timeouts=0 ^= no limit
ver=200480501133
channel=channel.socket:172.17.68.7:9009
max_connections=0
connectTimeout=0
replyTimeout=0
prepostTimeout=0

[ajp13:172.17.68.8:8009]
info=Worker 3 fuer Channel 3. max_connections and timeouts=0 ^= no limit
ver=200480501132
channel=channel.socket:172.17.68.8:8009
max_connections=0
connectTimeout=0
replyTimeout=0
prepostTimeout=0

[ajp13:172.17.68.8:9009]
info=Worker 4 fuer Channel 4. max_connections and timeouts=0 ^= no limit
ver=200480501132
channel=channel.socket:172.17.68.8:9009
max_connections=0
connectTimeout=0
replyTimeout=0
prepostTimeout=0

[status:status]
info=Status worker JKStatus, zeigt runtime informationen u.ae.
styleMode=1

# -----------------------------------------------------------
# Loadbalancer
# -----------------------------------------------------------
[lb:loadbalancer]
info=Loadbalanced Worker Gruppe
ver=200480501137
noErrorHeader=1
timeout=10
recovery=10
attempts=3
stickySession=1

# -----------------------------------------------------------
# URI-Mappings (Java-Web's und Kontexte)
# -----------------------------------------------------------

# Der JK2-Status Kontext
[uri:/jkstatus/*]
info=The Tomcat /jkstatus handler
ver=200407232
worker=status:status

# Testweb 1: Nur JSP-Examples
[uri:web1.wwwpoc.test/jsp-examples/*]
info=Standard-Examples, u.a. Snoop.jsp
ver=200407232
debug=info
disabled=0
group=lb:loadbalancer

# Testweb 2: Ein illegaler Context
[uri:web2.wwwpoc.test/servlets-examplesoff/*]
info=Servlet-Examples, u.a. SessionExample
ver=200407235
debug=info
disabled=0
group=lb:loadbalancer

# Testweb 3: Servlet-Examples und JSP-Examples
[uri:web3.wwwpoc.test/jsp-examples/*]
info=Standard-Examples, u.a. Snoop.jsp
ver=200408501255
debug=info
disabled=0
group=lb:loadbalancer

[uri:web3.wwwpoc.test/servlets-examples/*]
info=Servlet-Examples, u.a. SessionExample
ver=200408501255
debug=info
disabled=0
group=lb:loadbalancer

# Testweb Webtest: Servlet-Examples, JSP-Examples und Doc's
[uri:webtest.wwwpoc.test/jsp-examples/*]
info=Standard-Examples, u.a. Snoop.jsp
ver=200407232
debug=info
disabled=0
group=lb:loadbalancer

[uri:webtest.wwwpoc.test/servlets-examples/*]
info=Servlet-Examples, u.a. SessionExample
ver=200407234
debug=info
disabled=0
group=lb:loadbalancer

[uri:webtest.wwwpoc.test/tomcat-docs/*]
info=Servlet-Examples, u.a. SessionExample
ver=200407234
debug=info
disabled=0
group=lb:loadbalancer