Version 1.0

[firEmergency]

Bitte Level auf DEBUG und nochmal posten.
Was uns jetzt interessiert ist das XML welches von FMS32 geschickt wird (steht ganz am Anfang des Alarms. Beginnt mit <event>...; Wird aber nur im DEBUG Level angezeigt).

Dein Problem was uns immer bewusst, wir konnten es aber nie reproduzieren. Deswegen hoffen wir mal durch das Ändern des Log-Levels auf DEBUG lässt sich mehr nachvollziehen.

[Narkose07]

Hier nun im Debug Modus:
Also meiner Meinung nach liegt der Fehler in der Doppelalarmierungsblockung.
Hier wird 55307 beim "2ten mal" geblockt, obwohl eigentlich zuerst der Benutzer "55307" und danach der Benutzer "GlobalAkt" aufgerufen wird.

Ich hoffe, dass ich weiterhelfen konnte.


18:13:53 [DEBUG] [Thread-6] [AlarmFMS32ExeInput.AlarmFMS32Input][79] Eingehende Alarmierung akzeptiert.
18:13:53 [DEBUG] [Thread-6] [AlarmFMS32ExeInput.AlarmFMS32Input][95] Line: <event>
18:13:53 [DEBUG] [Thread-6] [AlarmFMS32ExeInput.AlarmFMS32Input][95] Line: <address>55307</address>
18:13:53 [DEBUG] [Thread-6] [AlarmFMS32ExeInput.AlarmFMS32Input][95] Line: <description>FZ1</description>
18:13:53 [DEBUG] [Thread-6] [AlarmFMS32ExeInput.AlarmFMS32Input][95] Line: </event>
18:13:53 [DEBUG] [Thread-6] [AlarmFMS32ExeInput.AlarmFMS32Input][121] Alarm für 55307 wird gesendet
18:13:53 [INFO] [Thread-6] [server.AlarmPool][124] Neuer eingehender Alarm für "55307"
18:13:53 [INFO] [Thread-6] [server.AlarmPool][265] Alarm ist ein Sammelalarm
18:13:53 [DEBUG] [Thread-6] [server.AlarmPool][275] Added SA_Sammel to alarmsToStart
18:13:53 [DEBUG] [Thread-6] [server.AlarmPool][292] Remove [] from [SA_Sammel]
18:13:53 [DEBUG] [Thread-6] [server.AlarmPool][297] NewMassAlarm
18:13:53 [INFO] [Thread-6] [server.AlarmPool][298] Neuer Sammelalarm eingegangen mit 45000 MilliSekunden Wartezeit gestartet
18:13:53 [DEBUG] [Thread-6] [server.AlarmPool][301] Erstelle MassAlertingTimerTask für: SA_Sammel
18:13:53 [DEBUG] [Thread-6] [server.AlarmPool][234] Alarm hinzugefügt und Controller aufgeweckt
18:13:53 [WARN] [PipeControllerThread] [server.PipelineController][82] Alarm für 55307 wird nicht behandelt, da kein zugehöriger Alarmablauf gefunden wurde.
18:13:53 [DEBUG] [Thread-6] [AlarmFMS32ExeInput.AlarmFMS32Input][126] Eingehende Alarmierung weitergereicht
18:13:54 [DEBUG] [Thread-6] [AlarmFMS32ExeInput.AlarmFMS32Input][79] Eingehende Alarmierung akzeptiert.
18:13:54 [DEBUG] [PipeControllerThread] [server.PipelineController][158] Server legt sich schlafen!
18:13:54 [DEBUG] [Thread-6] [AlarmFMS32ExeInput.AlarmFMS32Input][95] Line: <event>
18:13:54 [DEBUG] [Thread-6] [AlarmFMS32ExeInput.AlarmFMS32Input][95] Line: <address>55307</address>
18:13:54 [DEBUG] [Thread-6] [AlarmFMS32ExeInput.AlarmFMS32Input][95] Line: <description>FZ1</description>
18:13:54 [DEBUG] [Thread-6] [AlarmFMS32ExeInput.AlarmFMS32Input][95] Line: <user>GlobalAkt</user>
18:13:54 [DEBUG] [Thread-6] [AlarmFMS32ExeInput.AlarmFMS32Input][95] Line: </event>
18:13:54 [DEBUG] [Thread-6] [AlarmFMS32ExeInput.AlarmFMS32Input][118] Alarm für GlobalAkt wird gesendet
18:13:54 [INFO] [Thread-6] [server.AlarmPool][102] >>>Mehrfachalamierung für "55307"
mit Nachricht ""
18:13:54 [DEBUG] [Thread-6] [AlarmFMS32ExeInput.AlarmFMS32Input][126] Eingehende Alarmierung weitergereicht
18:14:38 [WARN] [Timer-0] [server.AlarmPool][471] Sammelalarm-Task wurde abgebrochen da Trigger-Alarm nicht eingegangen!



Vielleicht ist es auch so ähnlich wie hier: http://www.funkmeldesystem.de/foren/...6&postcount=13

[firEmergency]

Nicht nur vielleicht.
Das ist exakt das gleiche Problem und mit 1.1 Beta behoben.

[Narkose07]

Könnte man ein solches Tool --> http://www.funkmeldesystem.de/foren/...ad.php?t=53682
nicht zukünftig in FE integrieren, so dass man sich auf "Knopfdruck" die "Einstellungsdaten" exportieren und ggf. speichern/drucken kann.

Diese könnte man dann zum aktuellen Datenabgleich (Aktualität der Nummern, Prowl,...) in der Organisation oder selbst als Sicherheitsdaten (falls der CONFIG Ordner aus irgendwelchen Gründen def. ist,...) nutzen.

[Beuti]

Könnte man ein solches Tool --> http://www.funkmeldesystem.de/foren/...ad.php?t=53682
nicht zukünftig in FE integrieren, so dass man sich auf "Knopfdruck" die "Einstellungsdaten" exportieren und ggf. speichern/drucken kann.

Diese könnte man dann zum aktuellen Datenabgleich (Aktualität der Nummern, Prowl,...) in der Organisation oder selbst als Sicherheitsdaten (falls der CONFIG Ordner aus irgendwelchen Gründen def. ist,...) nutzen.

Statement dazu hier: http://www.funkmeldesystem.de/foren/...6&postcount=11

[Narkose07]

Nicht nur vielleicht.
Das ist exakt das gleiche Problem und mit 1.1 Beta behoben.

Spitze! Dann wär das auch gelöst;)
Möchte nicht drängen, aber weiß man schon ungefähr bis wann die 1.1beta erscheinen wird?
Damit mir dann auch jeder Alarm "durchgeht" (ausgelöst wird). ;)

Vlg

[Narkose07]

Spitze! Dann wär das auch gelöst;)
Möchte nicht drängen, aber weiß man schon ungefähr bis wann die 1.1beta erscheinen wird?
Damit mir dann auch jeder Alarm "durchgeht" (ausgelöst wird). ;)

Vlg

Push ;) ;) ;)

[firEmergency]

:)
Wir werden uns nicht mehr zu einem genauen Termin hinreisen lassen.
Wenn wir den dann nicht schaffen, gibt es nur wieder "Ärger".

Wie sagen doch machen Spiele-Entwickler immer:

When it's done!

[Narkose07]

Gefällt mir ;)

[Narkose07]

Ja, FE ist durchaus in der Lage 1000de von Alarmen pro Tag abzuarbeiten, jedoch werden manchmal einige als Doppelalarmierungen erkannt und dann nicht ausgeführt.
Genaue Beschreibung siehe oben.
Der Fehler wurde durch das DEV-Team bereits gefunden und ist mit der 1.1 wsl. behoben.

Vlg