Troubleshooting

Haeufige Probleme beim Betrieb der Engine und deren Loesungen.

Engine startet nicht

Port bereits belegt

# Pruefen, welcher Prozess den Port belegt
lsof -i :10560
 
# Engine auf alternativem Port starten
docker run -p 8080:80 marketplace.processcube.io/processcube-io/processcube_engine

Authority nicht erreichbar

Wenn die Engine mit Authentifizierung konfiguriert ist, muss die Authority erreichbar sein:

# Authority-Verbindung testen
curl http://localhost:11560/.well-known/openid-configuration

Fehlende Umgebungsvariablen

Die Engine gibt beim Start Fehler aus, wenn erforderliche Konfiguration fehlt. Pruefen Sie die Logs:

# Docker-Logs anzeigen
docker logs <container-id>
 
# Umgebungsvariablen im Container pruefen
docker exec <container-id> env | grep -i engine

Datenbank-Probleme

Verbindung zur Datenbank fehlgeschlagen

Zusaetzliche -wal- und -shm-Dateien

Seit v20.10.0-insiders.6 laeuft SQLite im WAL-Journalmodus. Neben engine.sqlite liegen im Betrieb daher engine.sqlite-wal und engine.sqlite-shm. Beim ordentlichen Beenden werden sie zusammengefuehrt und entfernt — bleiben sie liegen, wurde der Prozess hart abgebrochen; der naechste Start raeumt auf. Wichtig fuer Backups: alle drei Dateien gehoeren zusammen, eine Kopie der reinen .sqlite-Datei kann einen unvollstaendigen Stand enthalten.

Migration fehlgeschlagen

Datenbank-Migrationen laufen automatisch beim Start. Bei Fehlern:

# Engine mit Debug-Logging starten
docker run -e logging__minLogLevel=debug \
  marketplace.processcube.io/processcube-io/processcube_engine

Connection Pool erschoepft

Bei vielen gleichzeitigen Prozessen kann der Connection Pool erschoepft werden:

{
  "database": {
    "sequelizeOptions": {
      "pool": {
        "max": 20,
        "min": 5,
        "idle": 10000
      }
    }
  }
}

Prozessstart

408 Request Timeout beim Starten

Eine Start-Anfrage wartet nur begrenzt auf ihre Rückmeldung. Läuft application/startRequestTimeoutInMs ab (Standard 60000 ms), antwortet die Engine mit 408 Request Timeout. Ursache ist in der Regel ein Fehler, der weder Start noch Abbruch gemeldet hat — die Engine-Logs zeigen den eigentlichen Grund. Mit 0 laesst sich das Zeitlimit abschalten.

400 ... is a Singleton and already running

Ein als Singleton markiertes Prozessmodell laeuft bereits. Gleichzeitige Starts erhalten diese Fehlermeldung sofort, statt bis zum Client-Timeout offen zu bleiben. Auch von Cronjobs ausgeloeste Starts fangen die Ablehnung ab und protokollieren sie. Vor einem erneuten Start die laufende Instanz beenden oder abwarten.

Extension-Probleme

Extension wird nicht geladen

1. Pruefen, ob die Extension im extensions/-Verzeichnis liegt
2. package.json der Extension muss ein gueltiges main-Feld haben
3. Extension-Include/Exclude-Filter in der Konfiguration pruefen:

{
  "extensions": {
    "include": ["*"],
    "exclude": []
  }
}

Extension-Konfiguration fehlt

Viele Extensions benoetigen Umgebungsvariablen. Pruefen Sie die Logs fuer fehlende Konfiguration:

docker logs <container-id> 2>&1 | grep -i "extension"

Performance

Langsame Prozessausfuehrung

Die Engine nutzt Worker-Prozesse fuer Runtime- und Query-Operationen. Der Worker-Pool kann konfiguriert werden:

{
  "runtimeExpressions": {
    "workerPoolSize": 4,
    "timeoutInMilliseconds": 60000
  }
}

Hoher Speicherverbrauch

• Pruefen Sie die Anzahl gleichzeitig laufender Prozessinstanzen
• Monitoring-Extension aktivieren fuer Metriken-Ueberblick: Monitoring
• Bei Docker: Memory-Limit setzen und Container-Stats beobachten

docker stats <container-id>

Docker-spezifisch

Volumes fuer persistente Daten

Ohne Volume gehen SQLite-Daten beim Container-Neustart verloren:

docker run -v engine-data:/root/.processcube/engine \
  -p 10560:80 \
  marketplace.processcube.io/processcube-io/processcube_engine

Netzwerk zwischen Engine und Authority

In Docker Compose kommunizieren Services ueber den Service-Namen:

services:
  engine:
    environment:
      - iam__baseUrl=http://authority:11560
    depends_on:
      - authority