Limitierung beim Gruppenhandling bei SF 6.7.x ff.?

  • Hallo in die Runde,

    ich bin im Zusammenhang mit der Verwendung verketteter Gruppen bei einer Kundenanlage auf ein merkwürdiges Problem gestossen:

    Der Kunde wollte den eigentlichen simplen Lösungsweg für ein banales Anrufhandling haben, bei dem Anrufe zunächst bei einem Benutzer für einige Sekunden klingeln, danach für weitere Sekunden an eine erste Gruppe von anderen Benutzern signalisiert werden und, falls diese nicht annehmen in einer zweiten Runde an weitere, andere Benutzer weitergegeben + wenn auch diese nicht abnehmen nach weiterer Klingelzeit auf der Mailboch landen.

    Gelöst wurde das dann tatsächlich durch eine Weitergabe an zwei Gruppen, die Ihrerseits jeweils über separate mehrstellige Rufnummern angewählt werden. So weit - so gut - funktionierte lange Zeit für verschiedene Szenarien bei genau diesem Kunden auch so.

    Mittlerweile ist der Kunde sehr stark gewachsen, hat ein zigfaches an Mitarbeitern und eben auch zusätzliche Anforderungen. Beim Anlegen zweier weiterer in dieser Form verketteter Gruppen gab es nunmehr für die letzte neu angelegte Gruppenkombination plötzlich den Effekt, dass alle, in der zweiten Gruppe befindlichen Gruppenmitglieder, sich nicht mehr via PrepiumApp an der Starface anmelden können. Es ist eindeutig so, dass es sich um benannte Gruppenmitglieder handelt und auch nur diese - kein anderer Benutzer ist betroffen. Bei Entfernen eines Benutzers aus jener zweiten Gruppenstufe kann der sich auch sofort wieder anmelden.

    Gibt es für solche Gruppenkonstellationen mit Blick auf die Anzahl von Gruppen und Gesamtgruppenmitgliedern eine Limitierung?

    Die bisher genutzten Gruppen sind bezüglich der Gruppenmitglieder sehr umfangreich, wobei es eine untere zweistellige Anzahl von Gruppen gibt. Die betreffende Starface-Installation ist bis an die Grenzen des vom genutzten Linuxunterbau überhaupt verarbeitbaren RAM und CPU bestückt, hat also von dieser Seite technisch eher gar keine Mühe damit und verhält sich mit Blick auf genutzte Ressourcen auch komplett unauffällig und ruhiger als so manche Standardinstallation ...

    Gibt es dazu irgendwelche Hinweise?

    @Starface?

  • Hallo Ulf

    FabianZ
    July 22, 2019 at 3:13 PM

    Kurz zusammengefasst:

    Die UCI-Request im UCC-Client, welche via XMPP gehen, dürfen maximal 1MB gross sein.

    Wenn sich ein Benutzer einloggt, und dann alle Informationen von der STARFACE erhalten soll, und das Total der Infos (Umleitungen, Gruppenmitgliedschaften ect.) über 1MB liegt, so kommt die Verbindung nicht mehr zu stande.

    Durchsuche mal den log nach dem

    Code
    org.apache.mina.filter.codec.ProtocolDecoderException: Stopped parsing never ending stanza (Hexdump: (redacted hex dump of never ending stanza))

    MfG


    Fabian

  • Hallo Fabian,

    danke für die Info - dann haben wir die Erklärung - da wird teils deutlich mehr transportiert (punktuell wohl über das Doppelte). Der Zusammenhang zum Umfang der UCI-Requests liegt dann sicher noch in Kombination an einer anderen Stelle, die ich hier gar nicht weiter erwähnen und beschreiben mag und die ich zum Glück nach längerer Überzeugungsarbeit dem Kunden ausreden konnte. Offenkundig wurde dann jetzt definitiv eine Schmerzgrenze überschritten - Dein Hinweis erklärt das jedenfalls.

    Das heißt aber auch, dass diese Limitierung auch bei Folgeversionen der SF gilt, oder?

  • Hallo Ulf

    Ich weiss nicht, ob dieser Bug je behoben wurde.

    Du müsstest sonst mal mit der Call Nummer ([Call#6932583] Stanza Error - XMPP Client) bei der STARFACE nachfragen, ob der daraus Entstandene Task in die STARFACE integriert wurde oder nicht.

    Bzw. du könntest die Openfire Konfiguration prüfen, ob dort immer noch der Wert für 1MB drinnsteht.

    MfG

    Fabian

  • Hallo Fabian,

    ich bin mir jetzt nicht sicher, ob ich an den richtigen Stellen dafür gesucht habe - in der mit bekannten Openfire-Konfiguration kann ich dazu nichts finden, aber vielleicht suche ich nach etwas Falschem oder an der falschen Stelle.

    Sicherheitshalber: Die betreffende Angabe wäre exakt wo zu finden?

  • Hallo Ulf

    Im anderen Thread habe ich ein gif,welches das ganze Zeigt.

    Das war jedoch via http statt https eingebunden, darum wurde es ggf. nicht angezeigt.

    Die STARFACE hat anscheinend den Wert in einer neueren Version auf 15503360 (15 Mb) gesetzt. (Geprüft auf 8.0.0.9)

    Aber solange du auf 6.7.3 bist, musst du den Wert manuell setzen:

    Per SSH auf die STARFACE Verbinden

    Wenn die SSH Session geöffnet ist oben Rechtsklick auf das Putty Fenster machen ==> Change Settings

    Bei Connection ==> SSH ==> Tunnel ==> Tunnels

    Source Port: 9090

    Destination. 127.0.0.1:9090

    Add

    Danach kannst du in deinem Browser auf 127.0.0.1:9090 gehen.

    Dort mit einem STARFACE Admin einloggen.

    Oben unter Server ==> System Properties

    Zu unterst eine neue Property Hinzufügen:

    Name: xmpp.parser.buffer.size

    Wert: 10485760

    MfG


    Fabian

  • Nachdem Fabians Hinweis goldrichtig war und die Openfire-Anpassung sofort eindeutig nachvollziehbare Besserung gebracht hat, gibt es bei jener Instalation jetzt noch eine andere Auffälligkeit, die vermutlich eine andere Ursache hat:

    Einer der Benutzer loggt sich mit seinem Windows-Client auf der Starface ein und dann beginnt nach einiger Zeit die sichtbare Chatverfügbarkeit in relativ schnellem Wechsel an und aus zu gehen. So ist das dann auf der Starface z.B. in BLFs sichtbar. Der Client bleibt auch selbst stabil angemeldet und zeigt sonst auf Seiten der Starface vermeintlich kein sonstig sichtbares Fehlverhalten.

    Der Nutzer selbst beschreibt es so, dass er den Client teils gar nicht nutzen kann - sich das bei Ihm als "unverbunden" darstellt (was es aber definitiv nicht ist) - im Client wird beim genutzten Softphone ein ! angezeigt - der Chat witzigerweise als verfügbar.

    Client-Alzheimer? =O

    Auf Seiten der Starface kann man auch sehen, dass selbst Anrufe dorthin geleitet werden - also von Seiten der Anlage auch technisch von einem vorhandenen Client ausgegangen wird. Mit Blick auf den auswertbaren Chatstatus des Benutzers sieht es so aus, als gäbe es "mehrere Anmeldungen des gleichen Accounts" mit uneindeutigem - unterschiedlichem Ergebnis der Auswertung des Chatstatus.

    Betroffen ist nur eben jener eine Nutzer (von über 350). Der Nutzer ist nicht neu - den gibt es so schon lange, funktioniert hat der bisher problemlos bis eben auch der sich zunächst nicht mehr anmelden konnte (siehe gelöstes Problem). Bei anderen Nutzern, die jenes erste Anmeldeproblem hatten, tritt das defitiv nicht auf.

    Wo kann man ansetzen?

    ... den Client hat der benutzer wohl schon mehrfach neu auf seinem PC installiert (nach vorherig, vollständiger Entfernung).

    In dem Fall handelt es sich aus rein organisatorischen Gründen (aktuell noch) um einen 6.7.x-Installation mit dem dafür passenden Client.

  • Hallo Ulf

    Auf der Anlage ist nicht zufällig eines meiner Statusmodule drauf?

    Also Statusgest. BLF / Umleitung / Gruppenbasierter Chatstatus o.ä?

    Ich hatte mal einen Fall, bei dem Sich dann zwei Chatstatus gebissen haben.

    Der Client blinkt dann z.b. zwischen Online & Abwesend hin & her, und zwar mehrmals pro Sekunde.

    MfG

    Fabian

  • Hallo Fabian,

    nein - von Deinen diesbezüglichen Modulen ist dort nichts installiert - hier wird ein eigenes Modul dafür verwendet (was es auch schon etwas länger als Deine diesbezüglichen Module gibt und auch etwas anders ausgerichtet ist ;)). Allerdings ist jenes Modul für den betroffenen Benutzer gar nicht aktiv und das Problem tritt auch dann auf, wenn das Modul bzw. dessen Instanzen komplett deaktiviert ist - in diese Richtung hatte ich auch schon gedacht.

  • Ich würde mal Testweise alle Haken im "Chat & Status ==> Status" deaktivieren, und schauen, ob es danach auftritt, wenn man es manuell Ändert.

    Wenn nicht, würde ich mal alle Haken ausser den "Chat-Status auf Abwesend stellen wenn im Outlook ein Termin geplant ist", wieder aktivieren, und erneut schauen, ob das Problem noch auftritt.

    Ebenfalls würde ich vorab schonmal das Log-Level im UCC-Client unter Hilfe ==> Protokollierung auf DEBUG umstellen, um ggf. später die Logs auslesen zu können.

    MfG

    Fabian

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!