• Dieses Thema ist leer.
Ansicht von 15 Beiträgen - 1 bis 15 (von insgesamt 27)
  • Autor
    Beiträge
  • #16033
    Anonym
    Inaktiv

    Hi,

    ich habe eine Client/Server Umgebung, beide mit Windows 7 Prof. Diese Konstellation lief nun viele Monate fehlerfrei, wenn auch etwas langsam beim Öffnen des Journals u. Adressbuch, aber noch erträglich.

    Da ich nicht so lange warten wollte, bis es unerträglich langsam wird, habe ich auf dem Server das Journal und Adressbuch auf MySQL umgestellt (MySQL 5.1 Ess.). Schnell noch ins Adressbuch die ca. 380 Einträge kopiert, soweit so gut, hat alles geklappt. Vor der Umstellung habe ich auf Client und Server noch sämtliche Updates eingespielt. Die Client-spezifischen Einträge f. MySQL in der „janrufmonitor.properties“ habe ich gemacht.

    Leider ist genau das Gegenteil eingetreten: Das Adressbuch ist auf dem Client extrem langsam und das Journal ist trotz neuer Anrufe leer.

    Ich habe mit ProcessExplorer beobachtet, dass der Client alle 5 Sekunden eine neue Netzwerkverbindung zum Server aufmacht (Port 5555) und alle 10 Sekunden in das „jam-0.log“ einen Eintrag macht. Habe ich richtig beobachtet, das jeder einzelne Adressbuch-Eintrag separat vom Server angefordert wird?


    [ WARNING - 01/Jul/2011:14:02:01 +0200 - JAM-SWT/JFaceUI-Thread-(non-deamon) - de.janrufmonitor.service.client.HttpImageProvider.getImage() - null ]
    [ WARNING - 01/Jul/2011:14:02:11 +0200 - JAM-SWT/JFaceUI-Thread-(non-deamon) - de.janrufmonitor.service.client.HttpImageProvider.getImage() - null ]
    [ WARNING - 01/Jul/2011:14:02:21 +0200 - JAM-SWT/JFaceUI-Thread-(non-deamon) - de.janrufmonitor.service.client.HttpImageProvider.getImage() - null ]
    [ WARNING - 01/Jul/2011:14:02:31 +0200 - JAM-SWT/JFaceUI-Thread-(non-deamon) - de.janrufmonitor.service.client.HttpImageProvider.getImage() - null ]
    [...]
    [ WARNING - 01/Jul/2011:15:29:37 +0200 - JAM-SWT/JFaceUI-Thread-(non-deamon) - de.janrufmonitor.service.client.HttpImageProvider.getImage() - null ]
    [ WARNING - 01/Jul/2011:15:29:48 +0200 - JAM-SWT/JFaceUI-Thread-(non-deamon) - de.janrufmonitor.service.client.HttpImageProvider.getImage() - null ]
    [ WARNING - 01/Jul/2011:15:29:58 +0200 - JAM-SWT/JFaceUI-Thread-(non-deamon) - de.janrufmonitor.service.client.HttpImageProvider.getImage() - null ]
    [ WARNING - 01/Jul/2011:15:30:08 +0200 - JAM-SWT/JFaceUI-Thread-(non-deamon) - de.janrufmonitor.service.client.HttpImageProvider.getImage() - null ]
    [ WARNING - 01/Jul/2011:15:30:18 +0200 - JAM-SWT/JFaceUI-Thread-(non-deamon) - de.janrufmonitor.service.client.HttpImageProvider.getImage() - null ]
    [ WARNING - 01/Jul/2011:15:30:28 +0200 - JAM-SWT/JFaceUI-Thread-(non-deamon) - de.janrufmonitor.service.client.HttpImageProvider.getImage() - null ]

    Nach Adam Riese dauert auf diese Weise das Öffnen des Adressbuches 528 * 10 Sekunden, also ca. 1,5 Std. Tatsächlich erschien das Adressbuch fast exakt nach nach dieser Zeit (siehe Code), stand dann aber mit der Meldung „Aktualisiere Ansicht…“ unendlich lange still, leider mit einem inaktiven „Abbrechen“ Button. Der JAM Client liess sich aber über das Systray Icon beenden.

    Er hat in der Zeit weder Log-Einträge produziert wurden, noch neue Netzwerkverbindungen aufgemacht. Die CPU-Last der javaw.exe lag konstant bei 0%.

    Was kann die Ursache für das dermassen schleppende Einlesen und der Adressen und Aktualisieren der Ansicht sein? Selbst wenn es nur 30 Adressen wären, würde das 2x 5 Minuten dauern.

    Netzwerkprobleme kann ich ausschliessen, ich nutze das lokale Netz intensiv und problemlos für Dienste (auch MySQL) und Dateitransfers.

    Auf dem PC mit dem JAM-Server funktionieren das MySQL-basierte Adressbuch und Journal korrekt und flüssig.

    Nach Öffnen des „leeren“ Journals auf dem Client steht im Logfile:


    [ WARNING - 01/Jul/2011:16:59:52 +0200 - JAM-Journal#Preloader-Thread-(non-deamon) - de.janrufmonitor.repository.HttpCallManager.getCallCount() - Client is not yet connected with the server. ]
    [ WARNING - 01/Jul/2011:16:59:52 +0200 - JAM-Journal#Preloader-Thread-(non-deamon) - de.janrufmonitor.repository.HttpCallManager.getInitialCallList() - Client is not yet connected with the server. ]
    [ WARNING - 01/Jul/2011:16:59:53 +0200 - JAM-SWT/JFaceUI-Thread-(non-deamon) - de.janrufmonitor.repository.HttpCallManager.getCallCount() - Client is not yet connected with the server. ]
    [ WARNING - 01/Jul/2011:16:59:53 +0200 - JAM-SWT/JFaceUI-Thread-(non-deamon) - de.janrufmonitor.repository.HttpCallManager.getCallCount() - Client is not yet connected with the server. ]

    Trotz Meldung („Client is not yet connected…“) ist der Client aber mit dem Server verbunden, denn 1.) sagt das der Server-Statusmonitor und 2.) werden Anrufe auf dem Client PC korrekt gemeldet (Popup).

    Was kann ich tun, damit JAM mit der MySQL Erweiterung auch auf dem Client funktioniert? Wo soll ich mit der Fehlersuche beginnen?

    #24082
    Thilo Brandt
    Keymaster

    Hallo AxelF,

    ich vermute bei deiner Konstellation und den beschrieben Probleme hast du auf dem Client den Servermaintained Modus aktiv. Das ist bei der Anzahl an Einträgen nicht machbar. Du musst auf dem Client auf den Fast-Client-Modus umsteigen. Das MySQL Modul muss dann auf dem Client installiert werden. Die Konfiguration greift dann auf die MySQL DB direkt zu und nicht erst noch über das Server Modul. Ansonsten hättest du Client -> Server -> MySQL -> Server -> Client als Transportroute und das wäre dann unererträglich langsam.

    Viele Grüße
    Thilo

    #24083
    Anonym
    Inaktiv

    Hi Thilo,

    danke für deine Antwort.

    Ja, du hast das richtig vermutet: An den Clients ist der Servermaintained Modus aktiv. Aber das war absichtlich so konfiguriert, weil ich befürchtete, dass es zu Doubletten kommt, wenn ich den Fast-Client-Modus einstelle.

    Ich habe das – ehrlich gesagt – gar nicht erst probiert, weil es mir praxisfern vorkam. In dieser Konstellation nehmen alle Clients und auch der Server Einträge in den MySQL DBs vor, denn ich kann ja an keiner Stelle definieren, wer der Master ist – respektive, dass nur der Server Einträge vornehmen darf. Das entspräche ja wieder dem Servermaintained Modus.

    Na jedenfalls sammeln sich – wie erwartet – nun im Journal Doubletten 😕

    Wie komme ich aus dieser Zwickmühle raus?

    Ich habe ein kleines Büro, besetzt mit 2 Personen, 5 PCs, plus dem PC, der als Server fungiert. Wir arbeiten an allen Rechnern produktiv. Wenn alle PCs laufen, sind 5 JAM-Clients aktiv. Pro Anruf habe ich nun (je nach MSN) bis zu 5+1 Einträge im Log. Die „Haupt-„MSN wird an jeden Client gemeldet. Eine andere nur an den Kollegen…

    Also nichts aufregendes. Das ist eine 0-8-15 Umgebung, wie sie sicher bei vielen JAM-Usern zu finden sein sollte.

    Ich habe sicher etwas falsch verstanden oder falsch konfiguriert… Gibt es noch Hoffnung für mich?

    Viele Grüsse
    Axel

    #24084
    Thilo Brandt
    Keymaster

    Hallo Axel,

    ok, bei dir scheinen jetzt alle Clients in die MySQL DB zu schreiben. Deaktivieren auf den Client die Regel für den Dienst „Protokollierung“ und lasse diese nur auf dem Server aktiv. Die Clients können nach wie vor lesen, aber nur der Server schreibt in die DB rein. Somit hast du quasi einen eigenen Servermaintained Modus geschaffen.

    Viele Grüße
    Thilo

    #24085
    Anonym
    Inaktiv

    Hi Thilo,

    @thilo.brandt wrote:

    Somit hast du quasi einen eigenen Servermaintained Modus geschaffen

    Ja, habe ich. Nein, eigentlich hast du 😛

    Zuerst war ich enttäuscht, dass ich den Dienst „Protokollierung“ partout nicht finden konnte. Also habe ich in einer virtuellen Maschine mal eine komplette Neu-Installation gemacht. Aber trotzdem konnte ich an keiner Stelle diesen Dienst finden.

    Da ich schon viel im Forum gelesen habe, weiss ich, dass deine Antworten immer präzise und überlegt sind, ergo muss der Fehler bei mir oder meiner Installation liegen. Also nochmal gesucht… und so ging es mir den ganzen Tag nicht aus dem Kopf, und bei jeder Gelegenheit habe ich mich auf’s Neue durchgeklickt und 20x deinen Beitrag gelesen.

    Bis die Erleuchtung kam: du schreibst „…die Regel für den Dienst „Protokollierung“…“

    In der Rubrik „Regel-Assistent“ wurde ich dann unter Regel „Standard #3“ fündig.

    Das hast du gut versteckt, man könnte das fast ein „Easter-Egg“ nennen. Ohne deinen Hinweis hätte ich dort niemals gesucht, denn „Standard #3“ klingt (für mich) eher nach einem Platzhalter, als nach einer scharfen Regel 😎

    Vielen Dank für deine Geduld und Hilfe!

    PS: Habe ich das How-To für diese Konstellation (Server+Client+MySQL) übersehen oder gibt es noch keines? Dann wird es Zeit und ich erkläre mich bereit dafür.

    #24086
    Thilo Brandt
    Keymaster

    Hallo Axel,

    freut mich, dass es doch noch geklappt hat 🙂

    @AxelF wrote:

    PS: Habe ich das How-To für diese Konstellation (Server+Client+MySQL) übersehen oder gibt es noch keines? Dann wird es Zeit und ich erkläre mich bereit dafür.

    ja, das gibt es in derTat noch nicht. Bisher gibt es nur die Anleitung aus dem Benutzerhandbuch. Wenn du dich als dransetzen magst, unterstütze ich gerne…

    Viele Grüße
    Thilo

    #24087
    Anonym
    Inaktiv

    Hallo Thilo,

    sorry, dass ich den alten Thread hier wiederbelebe, aber ich habe ein Versprechen abgegeben, welches ich leider nicht einhalten kann:

    Ich finde keinen Weg, den jAM zuverlässig an die MySQL DB zu binden. Er verhält sich unberechenbar. Ich habe das Fehlverhalten in den vergangene Monaten mehr oder weniger fluchend so hingenommen (und mit Screenshots dokumentiert, kann ich dir gern zukommen lassen), in der Hoffnung, dass mir dazu irgendwann eine Lösung einfällt – leider umsonst.

    Es ist teilweise so, dass für einen einzigen Anruf komplett unterschiedliche Resultate gezeigt werden:

    1.) das Popup zeigt nur die Rufnummer und den Vorwahlbereich (das ist bei mir leider die Regel, nicht die Ausnahme)
    2.) Im Subject der Benachrichtigungs-Mail steht dann wenigstens schon mal die Adresse des Anrufers, wahrscheinlich online ermittelt
    3.) Und im Journal steht der Name korrekt so wie im Adressbuch!
    Aber auch nicht zuverlässig: Für eine Nummer tauchen im Journal oft unterschiedliche Adresseinträge auf, Beispiel:
    3.a) Gestern steht im Journal korrekt „Lieschen Müller (privat)“.
    3.b) Einen Tag später steht zur selben Nummer z.B. „unbekannt (Lieschen)“.
    3.c) Zwei Tage später steht nur noch „E-plus“ als Name da !?!?

    Das kannte ich vor dem Umstieg auf die MySQL Erweiterung nicht. Wenn ich doch nur ein bisschen Java könnte, ich würde dir sofort eine Lösung coden. Dann bräuchte man das MySQL als zusätzliche Fehlerquelle gar nicht.

    Ich möchte nochmal kurz zurück spulen:

    Es ist mir unerklärlich, wie die Übertragung von ein paar 100 Kontakte vom Server zum Client so viel Zeit in Anspruch nehmen kann. Ich kann das Ganze sofort in PHP oder Delphi coden und die Adressen stehen in Null-Komma-Nix tabellarisch bereit, egal ob aus einer Textdatei oder aus einer MySQL DB. Meine „addressbook.db“ hat ungepackt schlappe 780kB.

    Liegt das an Java?

    Aktuell warte ich schon wieder auf die Anzeige des zu Testzwecken reanimierten (servergespeicherten) Adressbuchs. Seit 120 Minuten (!) steht da „Aktualisiere Ansicht“. Dann kam ein kurzes Zwischenresultat mit der Meldung, dass 600 Einträge zuviel sind, ich solle die Ansicht auf 0 (Null) Einträge reduzieren. Klar. Dann geht’s natürlich super-schnell 😉

    Aber inzwischen steht er wieder bei „Aktualisiere Ansicht“, obwohl er zwischenzeitlich bereits fertig war und die Ansicht im Hintergrund längst sichtbar ist. Das dauert nun nochmal 2 Stunden.

    Öffne ich dasselbe Adressbuch direkt auf dem Server, dann steht es innerhalb 1-2 Sekunden!

    ich vermute bei deiner Konstellation […] hast du auf dem Client den Servermaintained Modus aktiv. Das ist bei der Anzahl an Einträgen nicht machbar.

    Nicht machbar? Warum nicht? Liegt das an Java oder an deiner Implementation?

    Es gibt viele Beispiele, die belegen, dass das geht. Als Client/Server basiertes Beispiel fällt mir sofort die Monitoring Software von Online-USV ein. Auch komplett in Java, da kann man sich im Client locker viele 100 Zeilen Messdaten ansehen, die vom Server aus einer Textdatei gelesen und übertragen wurden…

    Ansonsten hättest du Client -> Server -> MySQL -> Server -> Client als Transportroute und das wäre dann unererträglich langsam.

    Das kann nur langsam sein, wenn man das absichtlich langsam macht.

    Wir haben es mit einer Client/Server Appl. zu tun. Der Client sendet die Anfrage „Gib mir mal sämtliche Kontakte“ an den Server. Der liest Text ein oder macht eine SQL Abfrage und gibt das Ergebnis 1:1 dem Client, in meinem Fall 600 Zeilen, knapp 800kB. Der Client wird das aufbereiten, als hätte er die Anfrage selbst durchgeführt und hat die Ansicht in wenigen Sekunden fertig. So sieht die zugehörige „Transportroute“ aus:
    Client –(10ms)–> Server –(10ms)–> MySQL –(10ms)–> Server –(2000ms)–> Client

    Ich weiss nicht ob mit Absicht oder nicht, aber an irgendeiner Stelle hast du eine Verzögerung eingebaut, die 4 Stunden Zeit vergeudet. Da würde auch kein Filter helfen.

    Die CPU-Last liegt bei 0,01%, Disk I/O = 0, Net I/O = 0. Alle 10 Sekunden werden ein paar Byte in „classloader.cache.lck“ geschrieben. Mehr tut sich in den 4 Stunden nicht! 😕

    Edit: Screenshot entfernt (war doppelt)

    #24088
    Thilo Brandt
    Keymaster

    Hallo Axel,

    das Problem in deinem Setup sind die Daten die über die Leitung gehen. Ich vermute du hast Bilder den Kontakten zugewiesen, die nicht unbedingt im Vorzugsformat JPG max. 110×90 Pixel sind. Folgendes passiert da.

    MySQL -> Server: Ist eine reine SQL Abfrage, soweit bin ich bei dir.

    Client -> Server: Ist eine eigene Protokollimpletierung von mir in Java umgesetzt, die nicht nur SQL Abfragen unterstützt sondern generisch ist um diverse Protokolle abzuspeisen.

    Da Kontakte im Adressbuch, ob Server oder Client ist egal, mehrdimensionale Daten enthalten kann, kann ich nicht einfach eine Tabelle übers Netz schieben. Das wäre die deutlich schnellere aber aber sehr eingeschränkte Lösung. Das Protokoll im Client ist dem HTTP Protokoll angelehnt, dass einzelne Tokens von Server holt. Hast du jetzt viele Informationen im Client angezeigt, werden nur die sichtbaren Daten per Konfiguration vom Server angefragt, der wiederum, in deinem Fall MySQL abfragt. Die Datenaufbereitung auf dem Client liegt jedoch in meiner Protkollimplementierung.

    Versuch mal die Spaltenanzahl im Adressbuch zu reduzieren, dann sollte die Übertargung auch schneller sein (nur Testweise). Wenn das geht, dann schau mal welche Binärdaten du im Adressbuch des Client anzeigte (Fotos, Notizen als PDF-Listen etc.). Diese werden dann natürlich auch komplett übertragen. Schau mal im Server ins access.log, was dort alles angefragt und an den Client geschickt wird.

    Irgendwo muss bei dir noch die Datenmenge übers Netzt gehen, sonst wüsste ich nicht was verzögern sollte. Von meiner Seite ist definitiv keine Verzögerung implementiert 😉

    Viele Grüße
    Thilo

    #24089
    Anonym
    Inaktiv

    Hallo Thilo,

    zuerst möchte ich dir danken, dass du meine langen Überlegungen durchgelesen hast und darauf eingehst. Ich versuche mich in Zukunft kürzer zu fassen 😉

    @thilo.brandt wrote:

    Ich vermute du hast Bilder den Kontakten zugewiesen, […]. Folgendes passiert da.
    MySQL -> Server: Ist eine reine SQL Abfrage, soweit bin ich bei dir.

    Nein, ich habe keine Bilder an die Kontakte zugewiesen und auch keine Notizen. Nur nochmal zum Verständnis, ich sitze zwischen zwei Stühlen (Problemen):

    Stuhl 1)
    Die textbasierten Journal+Kontakte benötigen unendlich viel Zeit (4h) und sinnvolle Kontakt-Ansichtsfilter lassen sich nicht setzen, da es keinen Filter gibt, der in eine Ansicht mit 25 Zeilen passt. Das Journal ist auf 30 Tage beschränkt.

    Stuhl 2)
    Das 4-Stunden-Problem tritt bei SQL *nicht* auf[1]. Dafür habe ich es hier mit widersprüchlichen bzw. unvollständigen Informationen zu tun. Ich hänge mal einen anonymisierten einen Screenshot dran, Bilder sagen mehr als 1000 Worte.

    Da die Arbeit mit den Textbasierten unmöglich ist, bleibt mir nur die MySQL Variante. Leider zeigt das Popup in diesem Modus fast immer nur die Anruf-Nummer an, selten mal Kontakte oder Angaben aus Reverse-Abfragen.

    @thilo.brandt wrote:

    Client -> Server: Ist eine eigene Protokollimpletierung von mir in Java umgesetzt, die nicht nur SQL Abfragen unterstützt …

    Hast du das mal mit Testdaten getestet und kommst du zu anderen Erkenntissen als ich? Ich kann dir gern meine DBs, Texte und Logs zur Verfügung stellen.

    @thilo.brandt wrote:

    Versuch mal die Spaltenanzahl im Adressbuch zu reduzieren, dann sollte die Übertargung auch schneller sein (nur Testweise).

    Zur Zeit habe ich folgende 4-Spalten Ansicht: Name, Adresse, Rufnummer, zuletzt angerufen

    @thilo.brandt wrote:

    Wenn das geht, dann schau mal welche Binärdaten du im Adressbuch des Client anzeigte (Fotos, Notizen als PDF-Listen etc.).

    Nichts davon, nix binäres. Reiner Text. Aktuell im Büro auch nur 2 Clients an 1 Server.

    @thilo.brandt wrote:

    Von meiner Seite ist definitiv keine Verzögerung implementiert 😉

    Habe verstanden 😎

    [1] Das MySQL basierte Journal benötigt ca. 5-8 Sekunden (Mit Filter auf 30 Tage), das Adressbuch benötigt immerhin 30 Sekunden (600 Kontakte), was auch ewig sein kann, wenn man drauf wartet. Nervig sind aber definitiv die unterschiedlichen oder unvollständigen Informationen in der Mail, Popup und Journal.

    #24090
    Thilo Brandt
    Keymaster

    Hallo AxelF,

    @AxelF wrote:

    Dafür habe ich es hier mit widersprüchlichen bzw. unvollständigen Informationen zu tun. Ich hänge mal einen anonymisierten einen Screenshot dran, Bilder sagen mehr als 1000 Worte.

    Ist das ein Screenshot eines Clients oder des Server? Blende mal die Spalte „Telefonbuch“ im Journal ein, um zu sehen über welches Modul die jeweiligen Kontakte identifiziert wurden. Du kannst auch mal das Traceing erhöhen, damit im jam-0.log protokolliert wird, welche Moduel bei der Identifizierung beteiligt sind. Siehe hierzu http://www.janrufonitor.de/logging

    @AxelF wrote:

    …Leider zeigt das Popup in diesem Modus fast immer nur die Anruf-Nummer an, selten mal Kontakte oder Angaben aus Reverse-Abfragen.

    Nur auf dem Client? Oder auch auf dem Server selbst?

    @AxelF wrote:

    Zur Zeit habe ich folgende 4-Spalten Ansicht: Name, Adresse, Rufnummer, zuletzt angerufen

    Die Spalte „Zuletzt angerufen“ ist z.B. eine sog. Interaktive-Spalte, diese wird durch einen Journal-Lookup „berechnet“. Nimm diese mal raus, dann sollte es einen deutlichen Geschwindigkeitvorteil geben.

    @AxelF wrote:

    …das Adressbuch benötigt immerhin 30 Sekunden (600 Kontakte), was auch ewig sein kann, wenn man drauf wartet.

    Die Spalte „Zuletzt angerufen“ dürfte hierfür der Grund sein !

    Viele Grüße
    Thilo

    #24091
    Anonym
    Inaktiv

    Hi Thilo,

    ich habe heute einige Einstellungen geprüft und umgestellt und werde den jAM mal ein Weile beobachten. Momentan hat sich einiges verbessert:

    * Durch Entfernen der Spalte „Zuletzt angerufen“ ist das Adressbuch flott geworden
    * Durch Anzeige der Quelle (Telefonbuch-Spalte) kam etwas Licht in das Dunkel der halb-korrekten Anzeige-Info. Dies brachte mich auch dazu, die Reihenfolge der Suche im Server zu konfigurieren – zuerst MySQL, dann x, dann y. Dort stand zuvor „DasOertliche“ als erstes. Warum der jAM das aber trotz falscher Reihenfolge mal so und mal so anzeigte, ist mir nicht klar geworden.

    Danke für die Denkanstösse. Ich melde mich mit Ergebnissen zurück.

    PS: Screenshot und sonstiges Verhalten bezog sich immer auf den Client. Wenn Server, dann habe ich immer darauf hingewiesen.

    #24092
    Thilo Brandt
    Keymaster

    Hallo Axel,

    kein Thema ! Lass uns (mich) wissen, was bei dir rausgekommen ist…

    Viele Grüße
    Thilo

    #24093
    Anonym
    Inaktiv

    Hallo Thilo,

    danke für Deine Geduld, hier ist das Ergebnis meiner Beobachtungen:

    1.) Im *Popup* wird der ermittelte Anrufer nicht angezeigt, obwohl die Identifizierung erfolgreich war. Im Journal und in der E-Mail sind die Caller-Daten korrekt.
    Was kann der Grund sein, dass das Popup die Informationen der erfolgreichen Caller-Identifizierung nicht erhält?


    [ INFO - 04/Okt/2012:19:11:19 +0200 - EventThread#1 - de.janrufmonitor.repository.identify.Identifier.getAllActiveCallerManagers() - List with all active caller managers: [MySqlAddressbook, http://www.DasOertliche.de, GoYellow.de, Gelbeseiten.de, 11880.com, CallerDirectory, CountryDirectory] ]
    [ INFO - 04/Okt/2012:19:11:19 +0200 - EventThread#1 - de.janrufmonitor.repository.identify.Identifier.identify() - ]
    [ INFO - 04/Okt/2012:19:11:19 +0200 - EventThread#1 - de.janrufmonitor.repository.identify.Identifier.identify() - Order of identification: [MySqlAddressbook, http://www.DasOertliche.de, GoYellow.de, Gelbeseiten.de, 11880.com, CountryDirectory] ]
    [ INFO - 04/Okt/2012:19:11:19 +0200 - EventThread#1 - de.janrufmonitor.repository.db.AbstractMultiPhoneCallerDatabaseHandler.process() - Found multi phone caller. ]
    [ INFO - 04/Okt/2012:19:11:19 +0200 - EventThread#1 - de.janrufmonitor.repository.db.AbstractMultiPhoneCallerDatabaseHandler.process() - Found call extension - for call number: 1573487XXXX ]
    [ INFO - 04/Okt/2012:19:11:19 +0200 - EventThread#1 - de.janrufmonitor.repository.identify.Identifier.identify() - Caller identified by [MySqlAddressbook]: {CALLER: [UUID: b490c22c-3a01-0010-0080-e928aa240c05][Name: Mustermann -][Phonenumber: +49 (157) 3487XXXX]{extension=extension = , ln=ln = Mustermann, central-number=central-number = 1573487XXXX, callermanager=callermanager = MySqlAddressbook, add=add = , fn=fn = , city=city = E-Plus}} ]
    [ INFO - 04/Okt/2012:19:11:19 +0200 - EventThread#1 - de.janrufmonitor.repository.identify.Identifier.identify() - ]

    2.) Obwohl ein Caller-Eintrag im MySQL Adressbuch enthalten ist und dieses in der Reihenfolge auf dem Server als erstes steht, werden Anrufer über DasÖrtliche (oder andere nachfolgende) identifiziert:

    [ INFO - 25/Sep/2012:16:48:42 +0200 - EventThread#1 - de.janrufmonitor.repository.identify.Identifier.identify() - Caller was not identified by [MySqlAddressbook]: No caller entry found for phonenumber : 3474178700 ]
    [ INFO - 25/Sep/2012:16:48:42 +0200 - EventThread#1 - de.janrufmonitor.repository.AbstractWebCallerManager.getCaller() - Taking caller from cache: {CALLER: [UUID: 092f6bfc-3901-0010-0080-e928aa240c05][Name: Baumann Spedition und Baustoffhandel -][Phonenumber: +49 (34741) 78700]{ln=ln = Baumann Spedition und Baustoffhandel, str=str = Dornbergsweg, cntry=cntry = Deutschland, no=no = 4, callermanager=callermanager = http://www.DasOertliche.de, pcode=pcode = 06463, city=city = Reinstedt}} ]

    3.) Obwohl das „jAnrufmonitor Adressbuch“ *nicht* aktiviert ist, werden Anrufer darüber identifiziert (erkennbar im Journal in der Spalte „Telefonbuch“):

    [ INFO - 27/Sep/2012:16:58:00 +0200 - EventThread#1 - de.janrufmonitor.repository.identify.Identifier.getAllActiveCallerManagers() - List with all active caller managers: [MySqlAddressbook, http://www.DasOertliche.de, GoYellow.de, Gelbeseiten.de, 11880.com, CallerDirectory, CountryDirectory] ]
    [ INFO - 27/Sep/2012:16:58:00 +0200 - EventThread#1 - de.janrufmonitor.repository.identify.Identifier.identify() - ]
    [ INFO - 27/Sep/2012:16:58:00 +0200 - EventThread#1 - de.janrufmonitor.repository.identify.Identifier.identify() - Order of identification: [MySqlAddressbook, http://www.DasOertliche.de, GoYellow.de, Gelbeseiten.de, 11880.com, CountryDirectory] ]
    [ INFO - 27/Sep/2012:16:58:00 +0200 - EventThread#1 - de.janrufmonitor.repository.db.AbstractMultiPhoneCallerDatabaseHandler.process() - Found multi phone caller. ]
    [ INFO - 27/Sep/2012:16:58:00 +0200 - EventThread#1 - de.janrufmonitor.repository.db.AbstractMultiPhoneCallerDatabaseHandler.process() - Found multi phone caller. ]
    [ INFO - 27/Sep/2012:16:58:00 +0200 - EventThread#1 - de.janrufmonitor.repository.db.AbstractMultiPhoneCallerDatabaseHandler.process() - Found multi phone caller. ]
    [ INFO - 27/Sep/2012:16:58:00 +0200 - EventThread#1 - de.janrufmonitor.repository.db.AbstractMultiPhoneCallerDatabaseHandler.process() - Found multi phone caller. ]
    [ INFO - 27/Sep/2012:16:58:00 +0200 - EventThread#1 - de.janrufmonitor.repository.db.AbstractMultiPhoneCallerDatabaseHandler.process() - Found multi phone caller. ]
    [ INFO - 27/Sep/2012:16:58:00 +0200 - EventThread#1 - de.janrufmonitor.repository.db.AbstractMultiPhoneCallerDatabaseHandler.process() - Found multi phone caller. ]
    [ INFO - 27/Sep/2012:16:58:00 +0200 - EventThread#1 - de.janrufmonitor.repository.db.AbstractMultiPhoneCallerDatabaseHandler.process() - Found multi phone caller. ]
    [ INFO - 27/Sep/2012:16:58:00 +0200 - EventThread#1 - de.janrufmonitor.repository.db.AbstractMultiPhoneCallerDatabaseHandler.process() - Found multi phone caller. ]
    [ INFO - 27/Sep/2012:16:58:00 +0200 - EventThread#1 - de.janrufmonitor.repository.db.AbstractMultiPhoneCallerDatabaseHandler.process() - Found multi phone caller. ]
    [ INFO - 27/Sep/2012:16:58:00 +0200 - EventThread#1 - de.janrufmonitor.repository.db.AbstractMultiPhoneCallerDatabaseHandler.process() - Found multi phone caller. ]
    [ INFO - 27/Sep/2012:16:58:00 +0200 - EventThread#1 - de.janrufmonitor.repository.db.AbstractMultiPhoneCallerDatabaseHandler.process() - Found multi phone caller. ]
    [ INFO - 27/Sep/2012:16:58:00 +0200 - EventThread#1 - de.janrufmonitor.repository.db.AbstractMultiPhoneCallerDatabaseHandler.process() - Found multi phone caller. ]
    [ INFO - 27/Sep/2012:16:58:00 +0200 - EventThread#1 - de.janrufmonitor.repository.identify.Identifier.identify() - Caller was not identified by [MySqlAddressbook]: No caller entry found for phonenumber : 172702XXXX ]
    [ INFO - 27/Sep/2012:16:58:00 +0200 - EventThread#1 - de.janrufmonitor.repository.AbstractWebCallerManager.getCaller() - Number is not cached, start identifiing ... ]
    [ INFO - 27/Sep/2012:16:58:00 +0200 - EventThread#1 - de.janrufmonitor.repository.AbstractWebCallerManager.getCaller() - URL to call: http://www.dasoertliche.de/Controller?form_name=search_inv&ph=0172702XXXX ]
    [ INFO - 27/Sep/2012:16:58:00 +0200 - Thread-2453 - de.janrufmonitor.repository.web.RegExpURLRequester.go() - Content successfully retrieved from http://www.dasoertliche.de... ]
    [ INFO - 27/Sep/2012:16:58:01 +0200 - EventThread#1 - de.janrufmonitor.repository.identify.Identifier.identify() - Caller was not identified by [www.DasOertliche.de]: Phone number 172702XXXX not identified: Phone number 172702XXXX not identified. ]
    [ INFO - 27/Sep/2012:16:58:01 +0200 - EventThread#1 - de.janrufmonitor.repository.AbstractWebCallerManager.getCaller() - Number is not cached, start identifiing ... ]
    [ INFO - 27/Sep/2012:16:58:01 +0200 - EventThread#1 - de.janrufmonitor.repository.AbstractWebCallerManager.getCaller() - URL to call: http://www.goyellow.de/inverssuche/?TEL=0172702XXXX ]
    [ INFO - 27/Sep/2012:16:58:01 +0200 - Thread-2454 - de.janrufmonitor.repository.web.RegExpURLRequester.go() - Content successfully retrieved from http://www.goyellow.de... ]
    [ INFO - 27/Sep/2012:16:58:01 +0200 - EventThread#1 - de.janrufmonitor.repository.identify.Identifier.identify() - Caller was not identified by [GoYellow.de]: Phone number 172702XXXX not identified: Phone number 172702XXXX not identified. ]
    [ INFO - 27/Sep/2012:16:58:01 +0200 - EventThread#1 - de.janrufmonitor.repository.AbstractWebCallerManager.getCaller() - Number is not cached, start identifiing ... ]
    [ INFO - 27/Sep/2012:16:58:01 +0200 - EventThread#1 - de.janrufmonitor.repository.AbstractWebCallerManager.getCaller() - URL to call: http://www.gelbeseiten.de/yp/subscriberlist_search.yp?subject=0172702XXXX ]
    [ INFO - 27/Sep/2012:16:58:02 +0200 - Thread-2455 - de.janrufmonitor.repository.web.RegExpURLRequester.go() - Content successfully retrieved from http://www.gelbeseiten.de... ]
    [ INFO - 27/Sep/2012:16:58:02 +0200 - EventThread#1 - de.janrufmonitor.repository.identify.Identifier.identify() - Caller was not identified by [Gelbeseiten.de]: Phone number 172702XXXX not identified: Phone number 172702XXXX not identified. ]
    [ INFO - 27/Sep/2012:16:58:02 +0200 - EventThread#1 - de.janrufmonitor.repository.AbstractWebCallerManager.getCaller() - Number is not cached, start identifiing ... ]
    [ INFO - 27/Sep/2012:16:58:02 +0200 - EventThread#1 - de.janrufmonitor.repository.AbstractWebCallerManager.getCaller() - URL to call: http://www.11880.com/inverssuche/index/search?_dvform_posted=1&phoneNumber=0172702XXXX ]
    [ INFO - 27/Sep/2012:16:58:03 +0200 - Thread-2456 - de.janrufmonitor.repository.web.RegExpURLRequester.go() - Content successfully retrieved from http://www.11880.com... ]
    [ INFO - 27/Sep/2012:16:58:03 +0200 - EventThread#1 - de.janrufmonitor.repository.identify.Identifier.identify() - Caller was not identified by [11880.com]: Phone number 172702XXXX not identified: Phone number 172702XXXX not identified. ]
    [ INFO - 27/Sep/2012:16:58:03 +0200 - EventThread#1 - de.janrufmonitor.repository.identify.Identifier.identify() - Caller identified by [CountryDirectory]: {CALLER: [UUID: ad0a3c08-3a01-0010-0080-e928aa240c05][Name: ][Phonenumber: +49 (172) 702XXXX]{ln=ln = , add=add = , fn=fn = , city=city = Vodafone}} ]
    [ INFO - 27/Sep/2012:16:58:03 +0200 - EventThread#1 - de.janrufmonitor.repository.identify.Identifier.identify() - ]

    Identifiziert über das Länderverzeichnis? – „Caller identified by [CountryDirectory]“ ❓

    Das sind die drei übrig gebliebenen Punkte, die ich allein nicht klären bzw. lösen kann.

    #24094
    Thilo Brandt
    Keymaster

    Hallo Axel,

    @AxelF wrote:

    1.) Im *Popup* wird der ermittelte Anrufer nicht angezeigt, obwohl die Identifizierung erfolgreich war. Im Journal und in der E-Mail sind die Caller-Daten korrekt.
    Was kann der Grund sein, dass das Popup die Informationen der erfolgreichen Caller-Identifizierung nicht erhält?

    Lässt du die MySQL Identifizierung jetzt auch dem Client durchführen? Wenn ja, sollte auch nur auf dem Client Popup der Name erscheinen. Wenn du auf dem Server identifizieren lässt, dann erscheint auf dem Client nur dann der Namen wenn du Servermaintained Modus aktiv hast. Evt. ist hier noch was im Argen.

    @AxelF wrote:

    2.) Obwohl ein Caller-Eintrag im MySQL Adressbuch enthalten ist und dieses in der Reihenfolge auf dem Server als erstes steht, werden Anrufer über DasÖrtliche (oder andere nachfolgende) identifiziert:

    Wenn der Eintrag in MySQL 1:1 vorhanden ist muss dieser auch gefunden werden. Prio MySQL ist 1, wenn dieses ganz oben steht. Nur falls das keine Ergebnis liefert z.B. bei Nebenstellenanschlussen oder vekürzten Rufnummern, dann werden die nächsten Identifikationsquellen in der Liste genutzt. Da muss also noch was mit der Rufnummer oder dem Eintrag nicht stimmen.

    @AxelF wrote:

    3.) Obwohl das „jAnrufmonitor Adressbuch“ *nicht* aktiviert ist, werden Anrufer darüber identifiziert (erkennbar im Journal in der Spalte „Telefonbuch“):

    [ INFO - 27/Sep/2012:16:58:00 +0200 - EventThread#1 - de.janrufmonitor.repository.identify.Identifier.getAllActiveCallerManagers() - List with all active caller managers: [MySqlAddressbook, http://www.DasOertliche.de, GoYellow.de, Gelbeseiten.de, 11880.com, CallerDirectory, CountryDirectory] ]

    Also zu diesem Zeitpunkt muss das jAnrufmonitor Adressbuch (CallerDirectory) noch aktiv gewesen sein. Es erscheint noich in der Liste der aktiven Caller Managers (s.o.) und wird somit in die Identifizierung integriert.

    @AxelF wrote:

    Identifiziert über das Länderverzeichnis? – „Caller identified by [CountryDirectory]“ ❓

    Das ist der Fallback und kann nicht deaktiviert werden. Das Ländercode und Vorwahlverzeichnis enthält alle Ländercodes und Ortsvorwahlen, die zur Auflösung und Aufteilung von Rufnummern genutzt werden.

    Viele Grüße
    Thilo

    #24095
    Anonym
    Inaktiv

    Hallo Thilo,

    so früh schon auf und schon fit 😉

    Ich hatte nicht erwähnt, dass die Log-Auszüge alle vom Server stammen, aber das hast du ja gesehen. Auf dem Client werden nur Exeptions u.ä. geloggt (s.u.).

    zu 1.)

    Lässt du die MySQL Identifizierung jetzt auch dem Client durchführen?

    Ja, aber nicht *auch*, sondern *ausschliesslich*. Laut Deiner Empfehlung im Beitrag vom Fr 1. Jul 2011, 18:55 betreibe ich den Client seitdem im „Fast-Client-Modus“. Der Client sollte sich also über eine MySQL Abfrage (Prio=1) die Caller-Daten für das Popup holen, aber das klappt scheinbar nicht.

    Der folgende Log-Eintrag stammt vom Client. Klingt nach einem gelegentlichen MySQL Verbindungsproblem:

    [ SEVERE - 04/Okt/2012:21:11:36 +0200 - JAM-Editor#Preloader-Thread-(non-deamon) - de.janrufmonitor.repository.AbstractDatabaseCallerManager.getCallers() - Communications link failure due to underlying exception:

    ** BEGIN NESTED EXCEPTION **

    java.net.SocketException
    MESSAGE: Software caused connection abort: socket write error
    [..]

    Ich kann mit dem Client Log nicht viel anfangen. Es besteht fast nur aus diesen Exeptions. Manchmal auch „java.sql.SQLException: Database already connected.“

    zu 2.)
    …lasse ich mal aussen vor. Ich teste eben mal mit MySQL Logging und Wireshark, was da eigentlich passiert. Habe den Eindruck, dass der Client sich nicht immer mit dem MySQL Server verbinden kann und dann die o.g. Exeptions wirft. Ursache unklar.

    zu 3.)

    Also zu diesem Zeitpunkt muss das jAnrufmonitor Adressbuch (CallerDirectory) noch aktiv gewesen sein

    Das jAM Adressbuch ist auf dem *Server* seit mindestens 4 Wochen aus, d.h., die Checkbox „Datenablage aktiviert“ ist leer. Auf dem *Client* war es noch an und der Anrufer steht dort auch drin neben drei weiteren. Die Info kann also von dort gekommen sein, trotz Eintrag im MySQL und MySQL-Prio = 1. Habe es eben ausgeschalten und behalte das im Auge.

    Aber auf dem Server dürfte das jAM Adressbuch nicht in der Liste der aktiven Manager auftauchen. Warum tut es das trotzdem bzw. wie lässt sich das verhindern?

    [ INFO - 05/Okt/2012:18:02:11 +0200 - EventThread#1 - de.janrufmonitor.repository.identify.Identifier.getAllActiveCallerManagers() - List with all active caller managers: [MySqlAddressbook, www.DasOertliche.de, GoYellow.de, Gelbeseiten.de, 11880.com, CallerDirectory, CountryDirectory] ]
    [..]
    [ INFO - 05/Okt/2012:18:02:11 +0200 - EventThread#1 - de.janrufmonitor.repository.identify.Identifier.identify() - Order of identification: [MySqlAddressbook, www.DasOertliche.de, GoYellow.de, Gelbeseiten.de, 11880.com, CountryDirectory] ]

    In der Prio-Liste „Order of identification“ fehlt der, obwohl er genau da stehen müsste, denn dort ist er drin und nicht entfernbar.

Ansicht von 15 Beiträgen - 1 bis 15 (von insgesamt 27)
  • Du musst angemeldet sein, um auf dieses Thema antworten zu können.