osftslog

Diese Seite wurde automatisch aus dem Datenbank-Schema-Dump generiert und kann unvollständig oder fehlerhaft sein. Die Spalten und Datentypen sind aus dem Schema-Dump bestätigt; die Wertebereiche von flag1/flag2 und der Pipeline-Lifecycle sind zusätzlich empirisch aus enaio-Server-Logs (Version 11.0, Build 801/802) rekonstruiert.

Persistenter Status-Spiegel der enaio®-Volltext-Such-Pipeline (Full Text Search, FTS). Pro indexierbarem DMS-Objekt eine Zeile (Primärschlüssel osid), die für immer lebt — kein DELETE in den ausgewerteten Logs beobachtet. Keine Pull-Queue: jeder Zugriff erfolgt per osid-Lookup; die eigentliche Job-Queue der FTS-Pipeline ist oscpmqueue.

Bewirtschaftet ausschließlich von zwei Service-Workern:

  • index:<port> — FTS-Indexer-Service (Default-Port 8045), konsumiert die CP-Queues FULLTEXTIDX, FULLTEXTDOC, FULLTEXTFILTER, FULLTEXTLOCATION, FULLTEXTDELETE.

  • os-rendition-cache — Rendition-Service, konsumiert die CP-Queues RENDITION, RENRESET.

User-Clients greifen nie direkt auf diese Tabelle zu.

1. Spalten

Name Typ Länge Beschreibung

osid

int

nicht-null

DMS-Objekt-ID (Primärschlüssel, eindeutig pro Zeile). Verweist auf die Hauptobjekttabelle des jeweiligen Objekttyps (objectX.id).

ostype

int

nicht-null

enaio-Objekttyp-ID (haupttyp * 65536 + untertyp, siehe Objekttyp-ID). Beobachtete Beispielwerte u. a. 17, 262144, 262163, 262248, 393219.

date1

int

—

Trigger-Zeit — Zeitpunkt der letzten Objekt-Änderung, die eine (Re-)Indexierung ausgelöst hat. Format: Minuten seit Unix-Epoch (1970-01-01 UTC).

date2

int

—

Letzter Verarbeitungs-Zeitpunkt der Pipeline (gleiches Format wie date1). Wird bei jeder Statusänderung aktualisiert — auch bei Partial-Updates des Rendition-Workers. Bei einem INSERT initial identisch mit date1.

flag1

int

—

Index-Relevanz-Flag. In den ausgewerteten Logs durchgängig 1; 0 vermutlich = „nicht zu indexieren". Wird ausschließlich von Voll-`UPDATE`s des Indexers gesetzt; Partial-`UPDATE`s des Rendition-Workers lassen die Spalte unverändert.

flag2

int

—

Pipeline-Status-Code — siehe Wertebereich flag2. Mischung aus HTTP-Statuscode-Analogie (200/404/422) für Endzustände und herstellereigenen Codes (1001–1006) für Pipeline-Zwischenphasen.

instance

nvarchar

32

Worker-Instanz-Tag in der Form '<service-name>:<port>' (z. B. 'index:8045'). Variiert bei mehreren Indexer-Instanzen.

2. Wertebereich flag2

Wert Bedeutung

0

Objekt vom Indexer aus FULLTEXTIDX aufgenommen — wartet auf finalen Indexierungs-Lauf. INSERT setzt diesen Wert immer initial. Voll-UPDATE durch Indexer, vorausgehender Pickup: std.GetNextCPMessage(QueueNames='FULLTEXTIDX').

200

OK — Volltext erfolgreich indexiert. Voll-UPDATE durch Indexer, vorausgehender Pickup: std.GetNextCPMessage(QueueNames='FULLTEXTDOC').

404

Volltext-Rendition (noch) nicht im Cache verfügbar. Indexer triggert daraufhin via std.CreateCPMessages mit CreateRenditionMessages=true einen neuen Rendition-Job. Transienter Zustand.

422

Rendition liegt vor, Inhalt aber nicht (sinnvoll) indexierbar — z. B. PDF ohne extrahierbaren Text (Scan ohne OCR), Format-Inkompatibilität. Endzustand (kein automatischer Retry beobachtet).

1001

Rendition-Worker hat Job aufgenommen. Partial-UPDATE durch Rendition-Service, vorausgehender Pickup: std.GetNextCPMessage(QueueNames='RENDITION').

1002

Rendition fertig in Cache geschrieben (nach std.StoreInCacheByID). Partial-UPDATE durch Rendition-Service.

1003

Rendition-Worker beginnt produktiven Schritt. Geht deterministisch nach 1004.

1004

Rendition läuft / Ergebnis pending. Typischer Vorzustand von 200.

1006

Rendition übersprungen — kein Hash, keine Volltext-Datei verfügbar. Retry-Pfad.
Voll-UPDATE`s (vom Indexer) setzen `flag1, date1, date2, flag2, instance. Partial-UPDATE`s (vom Rendition-Service) setzen nur `date2, flag2.

3. Typischer Lifecycle einer osid

INSERT (flag2 = 0, durch Indexer aus FULLTEXTIDX)
  → UPDATE flag2 = 1001   (Rendition-Worker Pickup)
  → UPDATE flag2 = 1003 → 1004   (Rendition läuft)
  → UPDATE flag2 = 1002   (Rendition im Cache)
  → UPDATE flag2 = 200    (Indexer aus FULLTEXTDOC: erfolgreich indexiert)

Bei Objekt-Änderung wird ein neuer FULLTEXTIDX-Eintrag in oscpmqueue erzeugt; der Lifecycle beginnt von vorn mit flag2 = 0.

4. Beobachtete SQL-Patterns

-- Initiale Anmeldung (INSERT, vom Indexer)
INSERT INTO osftslog (osid, ostype, date1, date2, flag1, flag2, instance)
VALUES (2677570, 262248, 29657186, 29657186, 1, 0, 'index:8045');

-- Endzustand setzen (Voll-UPDATE, vom Indexer)
UPDATE osftslog
SET date1 = 29657186, flag1 = 1, date2 = 29657186, flag2 = 200, instance = 'index:8045'
WHERE osid = 2677570;

-- Pipeline-Zwischenphase (Partial-UPDATE, vom Rendition-Service)
UPDATE osftslog SET date2 = 29657186, flag2 = 1002 WHERE osid = 2677570;

-- Status-Lookup (vor jeder Operation)
SELECT * FROM osftslog WHERE osid = 2677570;

5. Verwandte Tabellen

  • oscpmqueue — die eigentliche CP-Message-Queue der Pipeline (Push-Pull-Mechanismus).

  • osftcontent — Volltext-Content-Speicher (vom Indexer als Quelle gelesen).

  • osfttab — Volltextsuche-Hauptindex-Tabelle.

6. Beteiligte Server-API-Jobs

Job Rolle bzgl. osftslog

std.GetNextCPMessage

Pickup aus oscpmqueue — startet jede Pipeline-Aktion. Der Queue-Name bestimmt, welche flag2-Werte folgen.

std.GetCPObjectInfo

Liefert dem Worker u. a. HasVolltextFile und Hash — beeinflusst, ob 1001 → 1006 (skip) oder 1003/1004 (arbeiten) gesetzt wird.

std.GetCPObjectIdxFulltext

Indexer-Lesepfad: holt den Volltext-Content (aus osftcontent bzw. dem Cache). Leeres Resultat → flag2 = 404.

std.CreateCPMessages

Vom Indexer aufgerufen, wenn Rendition nachgefordert werden muss (CreateRenditionMessages=true).

std.DispatchCPMessage

Nachbearbeitung einer abgeschlossenen Message.

std.CPRenditionChanged

Vom Rendition-Service nach Reason=TEXT / PAGECOUNT / … aufgerufen. Triggert Re-Indexierung (Übergang 200 → 1004).

ado.ExecuteSQL

Direkter SQL-Pfad, über den beide Worker osftslog lesen und schreiben.