Zeitverzögerung bei Übergabe Bosmon -> Firemergency

Hallo zusammen,

ich betreibe einen Server auf dem sowohl Bosmon als auch Firemergency läuft.
Ich werte nur Pocsag aus, filtere die gewünschten Ric´s heraus und schicke sie per Netzwerkereignis weiter an Firemergency, von dort per Prowl auf´s iPhone.
Es funktioniert soweit alles einwandfrei, nur sind bei Alarmierung mehrerer Ric´s manchmal ordentliche Zeitverzüge dabei, nun suche ich nach einem Grund hierfür.
Wenn also ein Einzelfahrzeug alarmiert wird, kein Problem, 2-5sek. ist der Alarm auf´m Handy.
Wenn jetzt fünf Fahrzeuge in Folge alarmiert werden, laufen diese bei Bosmon sagen wir mal innerhalb von 20sek. ein, das erste Fahrzeug kommt mit dem normalen Zeitverzug auf dem Handy an, dann dauert es 10-15sek. bis zum 2. wieder 10-15sek. bis zum 3. usw...
In Firemergency steht als Alarmzeit, die "verzögerte" Zeit.
Jetzt ist die Frage, ob das ganze an Bosmon liegt, an Firemergency oder aber an etwas ganz anderem!? z.B. Firewall oder ähnliches...

System: Windows XP mit Windows Firewall und Microsoft Essentials

Hat jemand das selbe Problem, oder sogar eine Lösung dafür?

Hi,
könnte es vielleicht an der Systemauslastung liegen, hast du mal geschaut was CPU und RAM zum Zeitpunkt der Alarme für Werte aufweisen.

Gruß

Hallo und erstmal vielen Dank für die schnelle Reaktion :-)

Also laut Taskmanager ist die Prozessorauslastung zum Zeitpunkt eines Alarmes bei ca. 40-50%
Die Auslagerungsdatei ist bei ca.570MB

System ist ein Intel Atom D510 mit 1,67GHz und 1GB Ram
Bosmon und Firemergency in neuster Variante
Internetanbindung per LAN über Router an KabelBW-Anschluß...

Ich habe jetzt nochmal getestet...

...wenn ich in Bosmon das Netzwerkereignis in Richtung Firemergency manuell teste ist das Phänomen das selbe, ich klicke 5x innerhalb 10sek. auf "TESTEN" und eine Minute lang kommt alle 10-15sek. der Alarm auf dem Handy an :-(
Taskmanager zeigt dabei um die 40-50% Systemauslastung bei 600MB Auslagerungsdatei!
Die Deaktivierung des laufenden Webservers bringt keine Änderung.

Die Werte klingen ja in Ordnung.
Wenn fe die eingehenden Alarme mit der Verzögerung anzeigt, könnte natürlich auch bosmon die Quelle sein. Ich würde empfehlen dort zusätzlich nachzufragen.

Also nochmal ausführlicher:

Im FE Log stehen die Zeiten (neuer eingehender Alarm für xxx) wie sie verspätet kommen?
Hast du auf Debug Level umgestellt? Dann kannst du sehen wann FE den Alarm entgegen genommen hat.

Hallo nochmal,

ich habe das Logging jetzt mal auf Debug umgestellt,wusste im Vorfeld leider nichts damit anzufangen :-)
Ich habe mich jetzt etwas eingelesen und denke das so hinbekommen zu haben!

Ich habe jetzt also mal wieder von Bosmon aus einen manuellen Alarm 5x hintereinander ausgelöst (innerhalb von max. 10sek.)

Das ganze Logging erspare ich Dir/Euch mal an dieser stelle und zeige mal den Teil, der für mich interessant erscheint:

22:57:27 [INFO] [ProwlThread Tue Apr 24 22:57:27 2012] [server.PluginController][75] PluginController mit Plugin prowl.Prowl (XXXXX) mit AlarmData ()wurde gestartet
22:57:27 [DEBUG] [ProwlThread Tue Apr 24 22:57:27 2012] [server.PluginController][288] Das GUIElement person-iphone benötigt iphone-Information der Person
22:57:27 [DEBUG] [ProwlThread Tue Apr 24 22:57:27 2012] [prowl.Prowl][52] Pushdata:
22:57:27 [DEBUG] [ProwlThread Tue Apr 24 22:57:27 2012] [prowl.Prowl][57] application: nur XXXXX
22:57:27 [DEBUG] [ProwlThread Tue Apr 24 22:57:27 2012] [prowl.Prowl][62] event: Einsatzalarmierung
22:57:27 [DEBUG] [ProwlThread Tue Apr 24 22:57:27 2012] [prowl.Prowl][64] priority: Gering
22:57:27 [DEBUG] [ProwlThread Tue Apr 24 22:57:27 2012] [prowl.Prowl][66] description: N/A - N/A
22:57:27 [DEBUG] [ProwlThread Tue Apr 24 22:57:27 2012] [prowl.Prowl][95] Push für API-Key: XYZ
22:57:28 [INFO] [ProwlThread Tue Apr 24 22:57:27 2012] [prowl.Prowl][104] Senden an XYZ: API call succeeded. 997 api calls left.
22:57:28 [DEBUG] [ProwlThread Tue Apr 24 22:57:27 2012] [prowl.Prowl][105] Push erfolgreich!
22:57:28 [INFO] [ProwlThread Tue Apr 24 22:57:27 2012] [server.PluginController][140] PluginController mit Plugin prowl.Prowl (XXXXX) mit AlarmData () nach 391 ms beendet
22:57:28 [DEBUG] [XXXXXPipelineThread Tue Apr 24 22:57:27 2012] [server.Pipeline][281] Erstelle AlarmHistory
22:57:50 [DEBUG] [Thread-14] [server.gui.status.GStatusController$ServerThread][161] Neue Alarmierungen sind da
22:57:50 [DEBUG] [XXXXXPipelineThread Tue Apr 24 22:57:27 2012] [server.Launcher][430] 1 Oberflächen wurden über neue Alarmierungen informiert
22:57:50 [DEBUG] [Thread-14] [server.gui.MainFrame][693] Aktualisierung der AlarmHistory gestartet
22:57:50 [INFO] [XXXXXPipelineThread Tue Apr 24 22:57:27 2012] [server.Pipeline][305] Alarmabarbeitung beendet
22:57:50 [INFO] [XXXXXPipelineThread Tue Apr 24 22:57:27 2012] [server.Pipeline][138] Pipeline von Feuerwehr (XXXXX) wurde nach 23328 ms beendet, isError?: false
22:57:50 [DEBUG] [HistoryThread] [server.gui.MainFrameController][190] Füge Eintrag zu History hinzu
22:57:51 [DEBUG] [PipeControllerThread] [server.PipelineController][158] Server legt sich schlafen!
22:57:51 [INFO] [Thread-3] [server.AlarmPool][124] Neuer eingehender Alarm für "0000"

....

So, es ist also so, das Immer bei "Erstelle AlarmHistory" knappe 10-15sek. verloren gehen und erst danach ein neuer Alarm bearbeitet wird.
Ich bin mir nun nicht sicher, ob diese Erkennung des nächsten Alarmes an FE hängt oder wie Du bereits geschrieben hast ein Problem von Bosmon ist!?
Der geloggte "eingehende Alarm" ist also ebenfalls die verzögerte Zeit wie hier z.B. 22:57:51 und der letzte davor war ja 22:57:27 obwohl die Alarmierungen manuell keine 2sek. auseinander waren!

Ich werde es im BosMon-Forum auf jeden Fall auch mal thematisieren

Vielen Dank schon mal für Eure Hilfe

Anbei nochmal ein richtiger Alarm, alarmiert wurden 5Rics!
Das eine ist die Ansicht in BosMon mit den augewerteten Zeiten, das andere die anonymisierte Logdatei von FE!
Die "Push-Fehler" können ignoriert werden, Problem bekannt, Verzögerung war allerdings schon vor Auftreten dieser Fehler.

Aktuelle Antwort im BosMon-Forum:

"BosMon verzögert Ereignisse nicht. Sobald ein Ereignis ausgelöst wird, wird es auch sofort ausgeführt."

Problem:
Liegt an uns

Lösung:
Auf Update warten.
Alarm-History löschen.

Wie groß ist denn deine Alarm-History (im Ordner /Config/)?
Hast du viele Alarmierungen gespeichert?
Kannst du uns eventuell deine AlarmHistory zukommen lassen (via http://support.firemergency.de)

Hallo,

jetzt mit dem Log ist der Fehler greifbar. Der Fehler liegt an FE.
Wir haben ihn bereits auf die Liste genommen, danke für's Melden.

Gruß

Hallo nochmal,

vielen Dank für die schnelle Hilfe!!!
Meine AlarmHistory hat 5,5MB, allerdings habe ich von mir aus keine Alarme gespeichert.
Ich habe die Datei jetzt gelöscht und Server neu gestartet, mit dem Ergebnis, dass alles einwandfrei funktioniert *Begeisterung*
Kann ich verhindern, dass sie wieder so groß wird?
Datei schicke ich Euch.

Vielen Dank für die Hilfe, Service wirklich 1A*

Alarmierungen werden automatisch in der AlarmHistory gespeichert.
Weißt du ungefähr wie viele Alarmierungen du seit Start hattest?
10, 100, 1000?

Das Löschen der History ist eine temporäre Lösung. Aber dein Fehler hat uns ein grundlegendes Problem aufgezeigt, welches wir noch lösen werden.

Also ich schätze mal so circa 10-15 am Tag seit 13.02. laut AlarmHistory und Zeitweise hatte ich den Reichweitenalarm eingeschalten, dieser Ric ist wohl auch mit in der Historie.
Reichweitenalarm habe ich wieder abgeschalten, weil der Ric in der Übersicht der Serveroberfläche auftauchte, obwohl ich ihn zum "nicht anzeigen" eingestellt hatte, bei alle 3min. sind das in 24h eine Menge...

In der AlarmHistory sind Alarme seit 13.02. eingetragen, kann sein, dass ich da den neuen Server in Betrieb genommen habe, komisch ist aber, dass der letzte Alarm vom 05.04.2012 ist, obwohl die Datei ja vorgestern (also 24.04.) gesichert wurde.

Naja, Datei schicke ich soeben raus...