Problem beim Import von ics-Einträgen aus Webdatenquelle, Cache-Dauer

[trent]

Hallo Helmut,

es gibt ein Problem bei Benutzung der Funktion "iCal aus Webdaten". Ich habe als Quelle die ICS-Datei eines öffentlichen Google-Kalenders angegeben. Setze ich die Cache-Dauer auf 0 (was der Voreineinstellung entspricht), so wird anscheinend fortlaufend auf die Webquelle zugegriffen; es finden sich nach kurzer Zeit tausende Log-Einträge der Art

A new entry in table "tl_calendar_events" has been created (ID: 483461) ...

Das geht soweit, dass die Responsivität der Webseite spürbar sinkt.

Gedacht ist eigentlich, dass diese in regelmäßigen Abständen neu geladen wird (-> Cache-Dauer auf 86400, also einmal pro Tag). Setze ich die Cache-Dauer allerdings auf diesen Wert, so geschieht oben genanntes Fehlverhalten einen Tag nachdem ich diese Einstellung eingestellt habe.

Was mache ich da wohl falsch; könnte es an einer Fehlkonfiguration des Webservers liegen? Schöne Grüße,

Robert

[hschottm]

Hallo Robert,

Hallo Helmut,

es gibt ein Problem bei Benutzung der Funktion "iCal aus Webdaten". Ich habe als Quelle die ICS-Datei eines öffentlichen Google-Kalenders angegeben. Setze ich die Cache-Dauer auf 0 (was der Voreineinstellung entspricht), so wird anscheinend fortlaufend auf die Webquelle zugegriffen; es finden sich nach kurzer Zeit tausende Log-Einträge der Art

A new entry in table "tl_calendar_events" has been created (ID: 483461) ...

Das geht soweit, dass die Responsivität der Webseite spürbar sinkt.

Gedacht ist eigentlich, dass diese in regelmäßigen Abständen neu geladen wird (-> Cache-Dauer auf 86400, also einmal pro Tag). Setze ich die Cache-Dauer allerdings auf diesen Wert, so geschieht oben genanntes Fehlverhalten einen Tag nachdem ich diese Einstellung eingestellt habe.

Was mache ich da wohl falsch; könnte es an einer Fehlkonfiguration des Webservers liegen? Schöne Grüße,

Robert

also ich glaube nicht, dass du das was falsch machst. Ich hab jetzt erst mal in der DCA-Datei den Default auf 86400 gestellt, das ist sicherlich sinnvoller.
Ich hab mir die Routine noch mal angeschaut, die die Überprüfung macht. Eigentlich müsste die auch nach einem Tag noch funktionieren. Da wird nur die aktuelle Zeit genommen, davon wird das letzte Änderungsdatum des Kalenders abgezogen und wenn das Ergebnis größer als der Cache-Wert ist, dann wird neu generiert. Durch das neu Generieren aktualisiert sich dann wieder das letzte Änderungsdatum des Kalenders. Also sollte das eigentlich gehen.
Ich habe eine kleine Änderung gemacht und erzwinge die Datenbankabfrage, die sich die Zeit des Kalenders holt jetzt ungecached, da es evtl. sein kann, dass der Datenbank-Cache zuschlägt und die Zeit der letzten Änderung nicht als aktualisiert angezeigt wird.

Ich hoffe mal, dass es damit dann jetzt auch funktioniert.

LG,
Helmut

[trent]

Ich habe eine kleine Änderung gemacht und erzwinge die Datenbankabfrage, die sich die Zeit des Kalenders holt jetzt ungecached, da es evtl. sein kann, dass der Datenbank-Cache zuschlägt und die Zeit der letzten Änderung nicht als aktualisiert angezeigt wird.

Ich hoffe mal, dass es damit dann jetzt auch funktioniert.

Hallo Helmut,

Ich hab mir die aktualisierte Version installiert und probiere das jetzt mal aus. Zumindest hat sich o.g. Verhalten direkt nach Reaktivierung nicht mehr gezeigt; ich warte jetzt mal noch einen Tag ab. Schon mal vielen Dank, LG,
Robert

[trent]

Hallo nochmal,

leider ist genau 24h (86400 Sek.) nach Wiederaktivierung der Update-Funktion für den Kalender der selbe Fehler aufgetreten; allein in einer Minute werden 630 Log-Einträge alle der selben Art (A new entry in table "tl_calendar_events" has been created...) generiert; seit heute Mittag alleine über 20000, anscheinend bei jedem Seitenaufruf. Wenn ich zum Debuggen noch etwas überprüfen soll oder weitere Angaben machen kann, mach ich das gerne.

Schönen Gruß,

Robert

[do_while]

Hallo trent,

Bitte prüfe mal die Rechte der Dateien mit den Diagnosetool. Beispielsweise, wenn die localconfig.php von PHP nicht geschrieben werden kann, kann es passieren, dass wiederholt bei jedem Aufruf der Webseite der interne cron ausgeführt wird.

Sowas kann ggf. auftreten, wenn Du den SafeMode Hack benötigst, dieser aber nicht oder falsch angelegt ist.

[trent]

Hallo trent,

Bitte prüfe mal die Rechte der Dateien mit den Diagnosetool. Beispielsweise, wenn die localconfig.php von PHP nicht geschrieben werden kann, kann es passieren, dass wiederholt bei jedem Aufruf der Webseite der interne cron ausgeführt wird.

Hallo do_while,

Nein, da ist alles in Ordnung. Diagnosetool meldet nichts Verdächtiges, cron-jobs laufen regelmäßig und localconfig.php ist schreibbar und wurde erst heute geschrieben (hab ssh-Zugriff, Änderungsdatum der Datei von heute). SafeMode-Hack wird nicht benötigt und ist nicht aktiviert. Trotzdem Danke für den Tipp, schöne Grüße.