Konfiguration
In dem Bereich Konfiguration wird die aktuelle Serverkonfiguration gezeigt. Dabei sind die Parameter in alphabetische Reihenfolge sortiert. Um Parameter zu ändern, muss die Datei $BICSUITECONFIG/server.conf angepasst und der Scheduling Server neu gestartet werden. Falls die Umgebungsvariable BICSUITECONFIG nicht gesetzt ist, wird als Konfigurationsverzeichnis $BICSUITEHOME/etc verwendet.
Aus Sicherheitsgründen werden nicht alle Serverparameter dargestellt, das gilt insbesondere für Zugangsinformation für das Datenbanksystem.
Die derzeitigen Serverparameter sind:
Datei auditieren
???
Zeitplan Einträge
??(CalendarEntries) wieder englisch? Der Parameter definiert die maximale Anzahl Kalendereinträge pro Scheduled Event. Normalerweise wird der Parameter ??CalendarHorizon deutsch oder englisch klären?? zuerst Wirkung zeigen, aber für den Fall, dass innerhalb des Horizonts sehr viele Einträge anfallen, verhindert dieser Parameter, dass unsinnig viele Kalendereinträge vorgenommen werden. Da der Horizont pro Schedule definiert werden kann, könnte damit eine Art Denial of Service-Angriff vorgenommen werden.
Falls der Parameter nicht definiert wird, gilt als Default-Wert 300 Einträge.
Zeitplan Horizont [Tage]
???(CalendarHorizon)??? wieder englisch?
Der Parameter definiert den Default-Horizont für Kalender.
Falls der Parameter nicht definiert wird, gilt als Default-Wert 62 Tage (immer min- destens zwei Monate).
CodePage
Der Parameter definiert den aktiven Zeichensatz. Der Parameter ist inzwischen obsolet.
CompatibilityLevel
Der Parameter CompatibilityLevel definiert, welche Optionen und Befehle vom Server als gültig erkannt werden. Mögliche Werte sind: BASIC, PROFESSIONAL und ENTERPRISE. Das maximale Level ist abhängig von der lizenzierten Version. Per Default wird das Compatibility Level auf die lizenzierte Version gesetzt.
DbLoaders
Der Parameter DbLoaders bestimmt wie viele Threads beim Startup des Servers für das Laden des Objektspeichers gestartet werden. Abhängig von der Anzahl vorhandenen Prozessoren kann eine höhere Anzahl Threads zu einer Beschleunigung des Serverstarts führen.
Als Default wird die Anzahl vorhandener Prozessoren, jedoch maximal 5 genommen.
DbUrl
Der Parameter DbUrl definiert, welche Datenbank der Server nutzen soll. Die gültige Syntax ist abhängig vom eingesetzten Datenbanksystem.
Verständlicherweise gibt es für diesen Parameter keine Default-Belegung.
DbUser
Der Parameter DbUser gibt an, unter welchem Benutzernamen mit der Datenbank gearbeitet werden soll.
Auch für diesen Parameter gibt es kein Default.
ExportVariables
Der Parameter ExportVariables ist eine Zusammensetzung zweier Konfigurationsparameter: ExportVariables und UserExportVariables. Die genannte Variablen werden beim Abholen eines Jobs als eine Liste von Key Value Pairs dem Job Server übergeben. Dieser wiederum hat die Möglichkeit, die Variablen in die Umgebung des zu startenden Prozesses zu setzen. Ob der Job Server dies tut, bzw. unter welchem Namen er die Variable in die Umgebung setzt, ist abhängig von der Konfiguration des Job Servers.
Diese Funktionalität wurde auf zwei Parameter aufgeteilt, da die Default-Belegung des Parameters ExportVariables die Liste der Standardvariablen ist. Um zu verhindern, dass der Administrator die gesamte Liste abschreiben muss, damit nur ein weiterer Parameter exportiert werden kann, gibt es die Möglichkeit, die zusätzlichen Variablen im Parameter UserExportVariables zu spezifizieren.
GCWakeup
In regelmäßigen Abständen werden ”veraltete” Objekte aus dem Objekt-Cache entfernt. Der Parameter GCWakeup definiert, wie viel Zeit zwischen den Aufräumarbeiten liegen soll. Es ist nicht sinnvoll, den Parameter mit einem niedrigen Wert zu belegen, da der Aufwand nur abhängig ist von der Anzahl vorhandener Objekte (im Wesentlichen die Submitted Entities) und nicht von der Anzahl aufzuräumender Objekte.
Der Default für diesen Parameter ist 240 (Minuten).
History
Der Parameter History definiert die Zeit, für die Information über Master-Instanzen von Job- bzw. Batch-Definitionen behalten wird. Ältere Jobs bzw. Batches werden nur dann im Objekt-Cache behalten, wenn sie noch in irgendeiner Weise aktiv, also weder final noch cancelled, sind.
Per Default wird die Information der letzten 10 Tage, also 14400 Minuten behalten.
History Limit
Der Parameter History Limit definiert die Zeit, für die Information über nicht mehr aktive Master-Instanzen von Job- bzw. Batch-Definitionen maximal behalten werden. Dieses Limit gilt, wenn der Parameter MinHistoryCount ungleich 0 gesetzt ist. Wenn History auf 10 Tage, History Limit auf 30 Tage und MinHistoryCount auf 10 gesetzt ist, werden für einen wöchentlichen Job bzw. Batch nur die letzten 4 bis 5 Ausführungen im Objekt-Cache gehalten.
Per Default wird die Information der letzten 10 Tage, also 14400 Minuten behalten.
Hostname
Der Parameter Hostname ist der Name des Scheduling Servers. Dies ist auch der Inhalt des Standard Job Parameters SDMSHOST.
Per Default wird hier ”localhost” gesetzt.
JdbcDriver
Der Parameter JdbcDriver definiert, welche Klasse als JDBC Driver verwendet wird. Der Name dieser Klasse ist abhängig vom eingesetzten Datenbanksystem. Diese Klasse muss im CLASSPATH auffindbar sein. Die CLASSPATH- Umgebungsvariable wird in die Datei $BICSUITECONFIG/java.conf gesetzt.
Es spricht für sich, dass für diesen Parameter kein Default-Wert vorgesehen ist.
MinHistoryCount
Der Parameter MinHistoryCount definiert die minimale Anzahl von Master-Instanzen einer Job- bzw. Batch-Definition, die im Objekt-Cache gehalten werden. Ein Job bzw. Batch, der nur selten zur Ausführung kommt, kann so deutlich länger, als durch den Parameter History definiert, im Objekt-Cache gehalten werden. Die maximale Zeit, die ein solcher Job bzw. Batch im Objekt-Cache gehalten wird, wird jedoch trotzdem durch den Parameter History Limit begrenzt.
Per Default ist der Parameter mit dem Wert 0 belegt und somit nicht aktiv.
MaxHistoryCount
Der Parameter MaxHistoryCount definiert die maximale Anzahl von Master- Instanzen einer Job- bzw. Batch-Definition, die im Objekt-Cache gehalten werden. Ein Job bzw. Batch, der sehr häufig zur Ausführung kommt, kann so deutlich kürzer als durch den Parameter History definiert im Objekt-Cache gehalten werden. Ein exzessiver Speicherverbrauch durch solche Jobs bzw. Batches kann dadurch vermieden werden.
Per Default ist der Parameter mit dem Wert 0 belegt und somit nicht aktiv.
PTEvalCycle
Der Parameter PTEvalCycle definiert, nach wie vielen Sekunden die erneute Ressourcenverteilung für einen Pool default-mäßig erfolgt. Es ist nicht sinnvoll, den Wert für PTEvalCycle kleiner als den Wert für PTWakeup zu wählen, da die erneute Verteilung erst nach dem Aufwachen des Pool Threads erfolgt.
Der Default für diesen Parameter ist 900 (Sekunden).
PTWakeup
Der Parameter PTWakeup definiert, nach wie vielen Sekunden der Pool Thread aufwachen soll, um für alle Pools deren PTEvalCycle abgelaufen ist, eine Neuverteilung der Ressourcen zu errechnen.
Per Default erfolgt alle 300 Sekunden eine Neuverteilung der Resources.
ParameterHandling
Der Parameter ParameterHandling definiert, wie der Server reagiert, wenn Parameter angesprochen werden, die nicht deklariert wurden. Die mögliche Werte sind:
| Wert | Bedeutung |
|---|---|
| STRICT | Falls ein nicht deklarierter Parameter benutzt wird, wird eine Fehlermeldung ausgegeben. |
| WARN | Es wird eine Warnung ins Logfile des Servers geschrieben. Der Wert der Variablen wird (so weit gefunden) zurückgegeben. |
| LIBERAL | Der Wert des Parameters wird, so weit gefunden, zurückgegeben. |
Aus Sicht der Software Engineering sollte ParameterHandling als STRICT definiert werden. Aus Sicht der Bequemlichkeit ist WARN oder LIBERAL vorzuziehen.
Die Default-Einstellung ist LIBERAL.
Port
Der Parameter Port definiert, welcher TCP-Port der Server zur Kommunikation mit den Clients benutzt. Die Wahl des Ports ist frei, soweit kein Port unter 1024 genutzt wird, da nur hochprivilegierte Benutzer dies können. Da der Scheduling Server so konzipiert ist, dass keine besonderen Privilegien für den Betrieb benötigt werden, sollte der Server daher auch keine besonderen Privilegien erhalten.
Der Default Port ist 2506.
PriorityDelay
Der Parameter PriorityDelay definiert, nach wie viel Zeit die (effektive) Priorität eines Jobs hochgestuft wird. Die automatische Erhöhung der Priorität verhindert, dass Jobs unendlich auf Resources warten.
Der Default ist 30 (Minuten).
PriorityLowerBound
Der Parameter PriorityLowerBound bestimmt die höchste Priorität, die durch normales Altern von Jobs erreicht werden kann. Ist der Parameter größer als 0, dann bleiben eine Anzahl Prioritätsstufen frei, die vom Administrator genutzt werden können, um bestimmte Jobs garantiert vorne in eine Warteschlange einzureihen.
Per Default ist der PriorityLowerBound auf 10 gesetzt.
RunMode
Der Parameter RunMode sollte in produktiven Umgebungen auf PRODUCTION gesetzt sein. In der Entwicklungsumgebung von independIT steht der Parameter gelegentlich auf TEST. Falls der RunMode auf TEST steht, ist ein Befehl ”RUN TEST . . . ” freigeschaltet. Es ist nicht definiert, welche Auswirkungen die Benutzung dieses Befehls hat, da er für Testzwecke genutzt wird. Es ist sehr wohl möglich, dass die Benutzung des Befehls zu Serverabstürzen führt.
Der RunMode steht auf PRODUCTION soweit er nicht explizit auf TEST gesetzt wurde.
ScheduleWakeup
Der Parameter ScheduleWakeup definiert, nach wie viel Zeit der Resource Scheduling Thread aufwacht. Da der Resource Scheduler nahezu keine Zeit beansprucht, wenn es nichts zu tun gibt, kann die Zeit zwischen zwei Aktivierungen relativ kurz gehalten werden.
Der Default-Wert beträgt 30 (Sekunden).
SelectGroup
Der Parameter SelectGroup definiert, welche Gruppe das Select Statement benutzen darf. Ist dieser Parameter nicht gesetzt, oder enthält er einen Namen einer nicht existierenden Gruppe, dürfen nur Mitglieder der Gruppe ADMIN das Select Statement benutzen.
Dieser Parameter existiert aus Gründen der Backward Compatibility.
ServicePort
Der Parameter ServicePort ist der Port, über den (nur) ein Administrator sich mit dem Server verbinden kann. Dieser Port kann genutzt werden um in Störungsfällen doch noch einen, in der Hauptsache lesenden, Zugriff auf dem Server zu haben.
Der Default-Wert ist die 2505.
SessionTimeout
Der Parameter SessionTimeout definiert, wie lange eine Session per Default idle sein darf, bevor der Server die Session terminiert. Im Normalfall spielt dieser Parameter nur für interaktive Sessions mit sdmsh eine Rolle.
Der Default ist 30 (Sekunden).
SingleServer
Der Parameter SingleServer ist ein Boolean-Wert. Steht er auf ”true”, geht der Ser- ver davon aus, dass kein weiterer Server Zugriff auf das Repository haben kann. Beim Hochfahren nach einem ”ungraceful shutdown” ignoriert er gesetzte Tickets und setzt sein eigenes Ticket. Sollte ein zweiter Server unerwarteterweise doch aktiv sein, wird dieser feststellen, dass das Repository jetzt einem anderen Server gehört, und die Arbeit einstellen. Wenn beide Server den Parameter auf ’true” haben, wird eine Art Ping-Pong-Effekt die Folge sein.
Die Default-Einstellung ist ”false”.
TTWakeup
Der Parameter TTWakeup definiert, wie häufig die Tickets im Repository mindestens erneuert werden. Werden mehrere Server eingesetzt, sollten die Parameter aufeinander abgestimmt sein (d.h. möglichst gleich).
Der Default ist 30 (Sekunden).
TimerHorizon
Der Parameter TimerHorizon definiert, wie weit der Timer Thread in die Zukunft schauen soll, um den nächsten Ausführungszeitpunkt eines Jobs zu finden.
Der Default ist 5 (Jahre).
TimerRecalc
Der Parameter TimerRecalc bestimmt, nach wie viel Zeit erneut versucht wird einen nächsten Ausführungszeitpunkt eines Jobs zu finden, nachdem die letzte Suche aufgrund des Erreichens des TimerHorizon abgebrochen wurde.
Der Default ist 5 (Tage).
TimerSuspendLimit
Der Parameter TimerSuspendLimit definiert die Zeit, nach der ein Job suspended submitted wird, falls der Server zur geplanten Submit-Zeit nicht aktiv war. Diese Grenze kann für jedes Scheduled Event individuell gesetzt werden. Wird dies jedoch unterlassen, gilt der Wert des TimerSuspendLimits.
Die Default-Zeit beträgt 15 (Minuten).
TimerWakeup
Der Parameter TimerWakeup bestimmt, in welchen Abständen der Timer Thread aktiviert wird. Ein hoher Wert führt zu Ungenauigkeiten bezüglich des tatsächlichen Submit-Zeitpunktes sowie potentiell lange Laufzeiten des Time Schedule-Vorganges. Ein niedriger Wert ist dagegen deutlich weniger schädlich.
Gute Erfahrungen wurden bis jetzt mit dem Default-Wert von 30 (Sekunden) gemacht.
TraceLevel
Der Parameter TraceLevel bestimmt, wie viel und welche Art Logging-Information der Server ins Logfile schreibt. Die untenstehende Tabelle zeigt, welche Art von Meldungen bei welchem Trace Level protokolliert werden:
| Art | Trace Level | Bemerkung |
|---|---|---|
| FATAL | Alle | FATAL-Meldungen werden bei einem schweren Fehlerzustand im Server protokolliert und sollten unverzüglich beim Support-Team von independIT gemeldet werden. |
| ERROR | Alle | ERROR-Meldungen werden bei auftretenden Fehlern protokolliert. Diese Art von Fehler sind deutlich weniger kritisch als Fehler der Klasse FATAL. Es ist empfehlenswert diese Art von Fehler zu untersuchen und, wenn möglich, ihre Ursachen zu beseitigen. |
| INFO | Alle | INFO-Meldungen geben eine wichtige oder interessante Information aus. Beispiele für solche Meldungen sind die Meldungen, die während der Startup-Phase des Servers geschrieben werden. |
| WARNING | >0 | WARNING-Meldungen sind interessante Meldungen, die häufig mit Bedienungsungenauigkeiten zu tun haben. Ein Beispiel dafür sind die Warnungen, die auftreten, wenn der Parameter ’ParameterHandling’ auf WARN oder STRICT gesetzt ist. |
| MESSAGE | >1 | MESSAGE-Meldungen sind relativ unwichtige Meldungen, die nichtsdestotrotz sehr interessant sein können. So werden zum Beispiel alle ausgeführten Befehle und ihre Ausführungszeit als MESSAGE protokolliert. |
| DEBUG | 3 | DEBUG-Meldungen sind Meldungen, die beim Troubleshooting hilfreich sein können. Allerdings führt Trace Level 3 zu einer gewaltigen Flut an Meldungen. Für den Normalbetrieb sind diese Meldungen wenig aussagekräftig und eher behindernd. |
TriggerHardLimit
Der Parameter TriggerHardLimit legt die maximale Anzahl fest, die ein und derselbe Trigger feuern kann.
Die Default-Einstellung ist 100.
TriggerSoftLimit
Wenn Trigger angelegt werden, ohne dass ein FireLimit spezifiziert wird, legt der Parameter TriggerSoftLimit die maximale Anzahl fest, die eine Instanz dieses Triggers feuern kann.
Die Default-Einstellung ist 50.
TxRetryCount
In manchen Fällen kann es sein, dass die Durchführung einer Transaktion fehlschlägt, obwohl die Transaktion semantisch und syntaktisch korrekt ist. In diesem Fall wird der Server erneut versuchen, die Transaktion durchzuführen. Wie oft dies passiert, wird durch den Parameter TxRetryCount definiert.
Default-mäßig werden maximal drei Versuche unternommen.
UserThreads
Der Parameter UserThreads bestimmt die maximale Anzahl Sessions, die gleichzeitig connected sein können. Benutzer die das Web-Frontend benutzen, müssen nicht in der vollen Anzahl mitgezählt werden, da der Zope-Server für jeden Kommunikationsschritt eine neue Verbindung mit dem Scheduling-Server aufbaut und wieder abbaut. Die Job Server dagegen bleiben im Normalfall mit dem Scheduling-Server verbun- den und belegen jeweils einen Thread.
WorkerThreads
Der Parameter WorkerThreads definiert, wieviele Threads für die Befriedigung lesender Abfragen gestartet werden sollen. Im Gegensatz zu den schreibenden Transaktionen sind viele lesende Transaktionen sehr aufwendig. Dabei werden insbesondere die lesenden Transaktionen aus dem Monitoring-Bereich genannt. Per Default werden zwei solche Threads gestartet. In größeren Umgebungen ist es sinnvoll, die Zahl zu erhöhen.