Home Foren Support für jAnrufmonitor 5.0 (Windows) JAM meldet Telefonate, speichert sie aber nicht mehr, Journal leer

  • Dieses Thema hat 5 Antworten, 2 Teilnehmer, und wurde zuletzt am vor 5 Jahre, 1 Monat von Anonym aktualisiert.
Ansicht von 6 Beiträgen - 1 bis 6 (von insgesamt 6)
  • Autor
    Beiträge
  • #47912
    Anonym
    Inaktiv

    Nach dem letzten JAM-Updaten habe ich Anfang des Monats auch Java 8 auf den neuesten Build 201 aktualisiert und die neueste VM Hotspot 25.201-b09 installiert. Vor dem Update hatte ich noch einmal in’s Journal gesehen, sah alles normal aus. Vermutlich seit dem JAVA-Update (genau sagen kann ich es nicht, ich habe eben zum ersten Mal nach dem Update wieder in’s Jounal gesehen) zeigt das Journal bei jedem beliebigen Zeitraum (auch bei „alle Anrufe“) nichts mehr an, die Liste ist einfach leer. Die MySQL-Tabelle „calls“ enthält +1800 Anrufe, allerdings ist der letzte Anruf dort vom 01.03., seitdem wurde offenbar nichts mehr abgelegt. Sehe ich in die jam-0.log, sehe ich JAVA-Fehler (die Logs gehen bis 5.3. zurück, auch da finden sich die Fehler schon). Hier meine Konfiguration und die frischeste Fehlermeldung:

    Program information jAnrufmonitor:

    version = 5.0.81 (Build: 20190218)

    […]

    java.runtime.name = Java(TM) SE Runtime Environment

    sun.boot.library.path = C:\Program Files\Java\jre1.8.0_201\bin

    java.vm.version = 25.201-b09

    jam.fritzbox.session.ispwdialogvisible = false

    java.vm.vendor = Oracle Corporation

    java.vendor.url = http://java.oracle.com/

    path.separator = ;

    java.vm.name = Java HotSpot(TM) 64-Bit Server VM

    file.encoding.pkg = sun.io

    jam.fritzbox.tr064off = false

    user.country = DE

    user.script =

    sun.os.patch.level =

    java.vm.specification.name = Java Virtual Machine Specification

    user.dir = C:\jAnrufmonitor

    java.runtime.version = 1.8.0_201-b09

    java.awt.graphicsenv = sun.awt.Win32GraphicsEnvironment

    java.endorsed.dirs = C:\Program Files\Java\jre1.8.0_201\lib\endorsed

    os.arch = amd64

    jam.fritzbox.session.counter = 0

    […]

    java.vm.specification.vendor = Oracle Corporation

    user.variant =

    os.name = Windows 10

    sun.jnu.encoding = Cp1252

    jam.installer.restart = false

    java.library.path = C:\jAnrufmonitor;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;[…]

    jam.installer.run = true

    java.specification.name = Java Platform API Specification

    java.class.version = 52.0

    sun.management.compiler = HotSpot 64-Bit Tiered Compilers

    os.version = 10.0

    […]

    Installed modules:

    Anrufsimulator = 3.0.6

    MySQL-Datenbank Journal = 2.0.14

    DasTelefonbuch.de = 1.0.16

    AVM FRITZ!Box Fon Monitor = 2.0.76

    PDF-Exportfilter für Journale = 2.0.3

    Notizenverwaltung = 3.0.4

     

     

    [ SEVERE – 14/Mär/2019:13:02:44 +0100 – JAM-SWT/JFaceUI-Thread-(non-deamon) – de.janrufmonitor.repository.AbstractDatabaseCallManager.getCallCount() – The server time zone value ‚Mitteleuropäische Zeit‘ is unrecognized or represents more than one time zone. You must configure either the server or JDBC driver (via the serverTimezone configuration property) to use a more specifc time zone value if you want to utilize time zone support. ]

    [ SEVERE – 05/Mär/2019:14:27:04 +0100 – ModalContext – de.janrufmonitor.repository.AbstractDatabaseCallManager.setCalls() – The server time zone value ‚Mitteleuropäische Zeit‘ is unrecognized or represents more than one time zone. You must configure either the server or JDBC driver (via the serverTimezone configuration property) to use a more specifc time zone value if you want to utilize time zone support. ]

    java.sql.SQLException: The server time zone value ‚Mitteleuropäische Zeit‘ is unrecognized or represents more than one time zone. You must configure either the server or JDBC driver (via the serverTimezone configuration property) to use a more specifc time zone value if you want to utilize time zone support.

    at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:129)

    at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:97)

    at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:89)

    at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:63)

    at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:73)

    at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:76)

    at com.mysql.cj.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:835)

    at com.mysql.cj.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:455)

    at com.mysql.cj.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:240)

    at com.mysql.cj.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:199)

    at java.sql.DriverManager.getConnection(Unknown Source)

    at java.sql.DriverManager.getConnection(Unknown Source)

    at de.janrufmonitor.repository.db.AbstractDatabaseHandler.connect(AbstractDatabaseHandler.java:91)

    at de.janrufmonitor.repository.db.AbstractCallDatabaseHandler.setCallList(AbstractCallDatabaseHandler.java:126)

    at de.janrufmonitor.repository.AbstractDatabaseCallManager.setCalls(AbstractDatabaseCallManager.java:35)

    at de.janrufmonitor.repository.AbstractDatabaseCallManager.setCall(AbstractDatabaseCallManager.java:30)

    at de.janrufmonitor.service.fritzbox.SynchronizerService.synchronize(SynchronizerService.java:556)

    at de.janrufmonitor.service.fritzbox.SynchronizerService$4.run(SynchronizerService.java:719)

    at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:113)

    Caused by: com.mysql.cj.exceptions.InvalidConnectionAttributeException: The server time zone value ‚Mitteleuropäische Zeit‘ is unrecognized or represents more than one time zone. You must configure either the server or JDBC driver (via the serverTimezone configuration property) to use a more specifc time zone value if you want to utilize time zone support.

    at sun.reflect.GeneratedConstructorAccessor22.newInstance(Unknown Source)

    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)

    at java.lang.reflect.Constructor.newInstance(Unknown Source)

    at com.mysql.cj.exceptions.ExceptionFactory.createException(ExceptionFactory.java:61)

    at com.mysql.cj.exceptions.ExceptionFactory.createException(ExceptionFactory.java:85)

    at com.mysql.cj.util.TimeUtil.getCanonicalTimezone(TimeUtil.java:132)

    at com.mysql.cj.protocol.a.NativeProtocol.configureTimezone(NativeProtocol.java:2241)

    at com.mysql.cj.protocol.a.NativeProtocol.initServerSession(NativeProtocol.java:2265)

    at com.mysql.cj.jdbc.ConnectionImpl.initializePropsFromServer(ConnectionImpl.java:1319)

    at com.mysql.cj.jdbc.ConnectionImpl.connectOneTryOnly(ConnectionImpl.java:966)

    at com.mysql.cj.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:825)

    … 12 more

    #47913
    Thilo Brandt
    Keymaster

    Hallo stefanwolf,

    die Lösung zu deinem Problem findest du in dieser FAQ: https://www.janrufmonitor.de/zeitzone/

    Viele Grüße
    Thilo

    #47914
    Anonym
    Inaktiv

    Hallo Thilo,

    einfach großartig! Zwar nichts für Computerlaien, aber die nutzen wohl auch keine MySQL-Ablage. Zum Glück bin ich ein alter Informatiker 😉

    Es hat geklappt — es wurde 5 neue Telefonate von heute sichtbar und als ich in den Einstellungen die Sync-Option kurz auf „immer gesamte Anrufliste der AVM FRITZ!Box Fon synchronisieren“ gestellt habe, hat JAM sich auch brav alle fehlenden seit dem Update am 1.3. nachgezogen!

    Ursprünglich habe ich seinerzeit auf MySQL umgestellt, weil ich in den vielen alten Threads zu hohem Speicherbedarf irgendwo gefunden habe, dass das helfen soll. Neue Diskussionen zu dem Thema scheint es nicht zu geben oder ich übersehe sie ebenso wie ich die o.a. FAQ. Die Leute klagen über ein paar hundert MB und auf meinem System (16GB RAM) reserviert sich JAM bei Archiveinstellung auf „ein halbes Jahr“ (rund 1800 Journal-Einträge) im Hintergrund, also ohne dass ich gerade im Journal blättere oder sonst etwas in JAM mache, gut 2,5 GB! Und die werden auch nicht etwa kleiner, wenn ‚mal richtig Dampf auf dem Kessel ist, das scheint der Mindestbedarf zu sein. In den letzten 2 Wochen ging das auf rund 250MB ‚runter und ich freute mich schon, aber das lag ja wohl schlicht daran, dass das Journal wegen des Zeitzonen-Problems nicht gelesen werden konnte. Das habe ich Doofie wie gesagt in der Zeit nie aufgemacht (tue ich nur extrem selten — meist um ein kürzliches Telefonat nachzusehen, der Filter steht daher auch auch „letzte 7 Tage“, aber der Filter scheint den Speicherbedarf überhaupt nicht zu beeinflussen, der regelt offenbar nur die Anzeige, aber nicht das Einlesen der vorhandenen Daten in den Arbeitsspeicher — so wirkt es jedenfalls). Ist das normal oder extrem ungewöhnlich? Ich weiß, Themawechsel — aber ich fürchte, es gibt schon einen entsprechenden (und aktuellen!) Thread zum Speicher und ich suche nur falsch — oder alle haben sich an den Speicherhunger gewöhnt?

    Viele Grüße, Stefan.

    #47919
    Anonym
    Inaktiv

    Okay, die positive Änderung am Speicherbedarf lag nicht am Datenbankproblem — nach einiger Zeit der Rechnernutzung (mehrere Minuten) geht auch jetzt nach der Zeitzonenkorrektur immer noch die Speicherbelegung von JAM von Anfangs 2,5GB auf unter 300MB zurück, das ist aber eindeutig erst seit dem letzten Update zu beobachten — davor war eigentlich bei jedem Blick in den Task-Manager der Speicher am Anschlag. Prima!!!

    Viele Grüße, Stefan.

    #47921
    Thilo Brandt
    Keymaster

    Hallo Stefan,

    also janrufmonitor-seidig wurde das Speichermanagemnent und Resource-Handling schon seit Jahren nicht mehr angefasst. Das kann beim letzten Update daher nicht beeinflusst worden sein. Was natürlich im Falle von Java dazu kommt ist die GC in Java. Wenn du Java Updates einspielst, kann es natürlich sein, dass Oracle hier Änderungen vornimmt. Etwas konkretes ist mir aber nicht bekannt.

    Viele Grüße
    Thilo

    #47935
    Anonym
    Inaktiv

    Das (Problembeseitignung durch das umfassende JAVA-Update) war auch eine Nebenhoffnung. Momentan passt jedenfalls alles — nochmal danke für das großartige Tool!

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