[Behoben] [7.3.1.3] StarfaceEventService Queue ist voll & Anlage stürzt ab

Es scheint, dass der StarfaceEventService ==> ExecutorComponent ==> singleThreadExecutorService seine Maximale Warteschlangengrösse erreicht, weil er seine Aufgaben nicht schnell genug Abarbeiten kann, bzw. stecken bleibt, da es nur ein erlaubtes Thread hat, und alle Aufgaben werden hinten nacheschaufelt, bis es an die Limite kommt.

Ich habe einen HEAP Dump gezogen, und diesen Analysiert.

Die Pendenten aufgaben sind zu 99% de.starface.core.component.security.authentication.AuthenticationEvent von Erfolgreichen/Nicht Erfolgreichen SIP-Anmeldungen, vermutlich weil der 5060 aus dem Internet erreichbar ist.

Ich habe in der Zwischenzeit einen Queuewatcher geschrieben, welcher die Queue beobachtet, so dass der Partner ggf. einen Alarm bekommt, falls sich zu viele Aufgaben anstauen.

Der Support konnte mir logischerweise nicht weiterhelfen, haben mich aber auf einen Beitrag aus dem Forum bezgl. Drittanbietermodule und 7.3 Verwiesen: RE: STARFACE 7.3.0.5 (Major Release) - Beta online . Sehr hilfreich. Danke

Ich hoffe dass ein Entwickler hier mitliest, und ich so ggf. etwas mehr Informationen dazu bekommen kann, was das Verursachen könnte.

Diese Anlagen haben ein Modul von mir, welches speziell Entwickelt wurde, und nur Informationen ausliest, und per XML-RPC bereitstellt.

Dies enthält u.a.:

• STARFACE Build / Version
• Letztes Update
• Hat es Terminalserver lizenzen?
• Uptime / RAM / CPU / Speicherplatz
• Updatevertrag bis
• Div. Lizenzinformationen
• Interne IP
• Status der Backups
• Installierte Module
• ...

Ich wüsste nicht, wie dies damit im Zusammenhang steht.

Ich hoffe hier auf Unterstützung von Seiten STARFACE

MfG

Fabian

Hallo Dirk

Sehe dass ich das machen kann.

Wir wissen nur nicht, wann es das nächste Mal passiert.

MfG

Fabian

diwe

Ich habe Folgendes Script geschrieben:

Es macht für jeden Java Prozess jeweils 5 JStacks mit dem -l und -e Parameter, und schläft dazwischen jeweils 2 Sekunden.

#!/bin/bash

echo Dumping...

ids=$(pgrep java)
idarray=($ids)
target=/tmp/jstackdump/
mkdir $target

for i in "${idarray[@]}"
do
    File1=$target"PID_"$i"_Stack1.txt"
    File2=$target"PID_"$i"_Stack2.txt"
    File3=$target"PID_"$i"_Stack3.txt"
    File4=$target"PID_"$i"_Stack4.txt"
    File5=$target"PID_"$i"_Stack5.txt"
    echo Working on PID: $i;
    echo Dumping Stack1 $File1;     
    jstack -l -e $i > $File1;
    sleep 2;
    echo Dumping Stack2 $File2;     
    jstack -l -e $i > $File2;
    sleep 2;
    echo Dumping Stack3 $File3;     
    jstack -l -e $i > $File3;
    sleep 2;
    echo Dumping Stack4 $File4;     
    jstack -l -e $i > $File4;
    sleep 2;
    echo Dumping Stack5 $File5;     
    jstack -l -e $i > $File5;
    sleep 2;
done

echo Dumping Completed. Please Download the Content of: $target

Passt das so für dich?

Der Code könnte natürlich mit einem Counter optimiert werden, bin aber zu faul dafür.

MfG

Fabian

diwe

Wir hatten vom Sonntag auf den Montag 4 Anlagen, bei denen die Queue wieder auf 10'000 geschossen ist nachdem über ein Monat ruhe war.

Bei dreien konnte ich per SSH die Stacktraces erzeugen.

Diese sind dem Ticket [Call#7768658] angehängt worden.

MfG

Fabian

Könnt ihr hier noch das Tag "Behoben in 8.X" hinzufügen?

MfG

Fabian