Neu Exporte immer zur konfigurierten Zeit ausführen anstatt nach Schema "Fixed-Delay"?

[things4it]

Hallo,

wenn ich es richtig verstehe werden die Exporte nach dem Schema "FixedDelay" generiert.

Also habe ich z.B. den Google-Shopping-Export auf 0:00 Uhr, Intervall 24 Stunde konfiguriert, wird er nur bei der ersten Ausführung um 0:00 Uhr gestartet.
Endet der Export am 01.01.2021 um 1:24 Uhr, startet der nächste Export am 02.01.2021 um 1:24 Uhr (01.01.2021 1:24 + 24 Stunden)

Sprich der Export verschiebt sich Tag für Tag.

Aber gerade für Exporte, wo eine Gegenseite (in dem Fall google-shopping), den Export zu einer bestimmten Uhrzeit abholt, ist das ja etwas doof.
Vorallem dann wenn man wie bei google-shopping einen Feed nur einmal am Tag abholen kann.
Sprich man importiert dort dann veraltete Preise und Bestände und zahlt ggf. für Shopping Kampagnien, obwohl die Artikel seit einem oder mehreren Tagen nicht mehr verfügbar sind.
Wir haben zwar ein Plugin in Testphase, was stündlich die Preise und Bestände der geänderten Artikel via API an google-shopping meldet, aber dessen Aktualisierungen werden natürlich auch mit dem veralteten Export überschrieben .

Die einzige dreckige Lösung die mir als JTL- Shop newbee einfällt, ist via SQL und crontab das Datum des letzten Starts (tcron#lastStart) zurück zu setzen - aber das ist mega der hack.

Daher ein paar doofe Fragen:

• Gibt es dafür andere/saubere Lösungen?
• Bin ich/wir einfach nur zu doof das richtig einzustellen oder habe das verhalten und den Core-Code falsch interpretiert?
• Ist dafür ein Feature geplant über den man ein cron immer zur selben Zeit ausführen kann, also nicht die "FixedDelay" variante (wäre super wenn von JTL dazu jemand was sagen kann)
  • Fixed Delay macht ja definitiv Sinn, aber bei gewissen Exporten ist es halt eher ein Nachteil

Danke und viele Grüße
Johannes

 

[artm]

Also habe ich z.B. den Google-Shopping-Export auf 0:00 Uhr, Intervall 24 Stunde konfiguriert, wird er nur bei der ersten Ausführung um 0:00 Uhr gestartet.
Endet der Export am 01.01.2021 um 1:24 Uhr, startet der nächste Export am 02.01.2021 um 1:24 Uhr (01.01.2021 1:24 + 24 Stunden)

Ehrlich gesagt, die Bezeichnung "Cron-Job" bei JTL Shop ist eine Verwirrung für mich, es sollte Aufgabenplaner oder Task Planner heißen,
im Wirklichkeit hat man keinen Cron-Job, die Auslöser sind Nutzer und Bots. Ich denke Grund dafür waren Shop Nutzer, die keinen Einfluss auf Hosting hatten.

Am besten erstellt man einen echten Cron-Job an, dann sollten die Exporte richtig laufen.

 

[things4it]

Am besten erstellt man einen echten Cron-Job an, dann sollten die Exporte richtig laufen.

die /includes/cron_inc.php wird bei uns wie von JTL empfohlen via crontab getriggert (falls du das meinst).
Ist also unabhängig von den Usern und hat keinen Einfluss auf die Verschiebung.

Die Selektion der Cron die gestartet werden erfolgt via folgendem SQL aus includes/src/Cron/Checker.php:82

SELECT tcron.*
FROM tcron
LEFT JOIN tjobqueue
    ON tjobqueue.cronID = tcron.cronID
WHERE (
    tcron.lastStart IS NULL
    OR IF(tcron.jobType = 'statusemail' AND tcron.frequency = 720,
            MONTH(tcron.lastStart) = MONTH(CURRENT_DATE - INTERVAL 1 MONTH),
            (NOW() > ADDDATE(tcron.lastStart, INTERVAL tcron.frequency HOUR))
        )
    )
    AND tcron.startDate < NOW()
    AND tjobqueue.jobQueueID IS NULL

Wenn ich da nicht komplett falsch geschaut habe ist es schon "by design" so das sich das immer verschiebt .

 

[artm]

Wenn crontab wirklich läuft und Startzeit immer verschoben wird, dann klingt das definitiv nach einem Bug.
Habe Shop "Cron-Jobs" nicht ausprobieren, aber das würde mich auch interessieren.

 

[things4it]

ja ich denke ein Bug ist es nicht, ist ja für Cron-Jobs die häufiger wie einmal am Tag laufen und etwas länger dauern ganz sinnvoll damit die sie nicht überschneiden ... .

Aber ja für den Fall google-shopping ist es nicht so praktisch.

Naja, wir behelfen uns jetzt folgendem SQL, das via crontab vom Betriebsystem ausgeführt wird:

UPDATE tcron SET
        lastStart = concat(DATE(lastStart), ' ', startTime)
WHERE
        cronID = 122 # id des Google-Shopping crons

Ist halt hacky die Tabelle zu manipulieren, vllt. hat ja jemand eine bessere Lösungen?

 

[artm]

Habe nicht verstanden, was du mit Überschneidung meinst und was dabei sinnvoll ist, wenn ich alle Jobs um selbe Uhrzeit auf einmal starte, dann sollten diese in der Warteschlange stehen oder nicht, dafür ist doch die Tabelle "tjobqueue" da, die Startzeit-Verschiebung für Cron-Job klingt für komplett unlogisch

Ich würde eher prüfen wieso dauert der Export so lange. Um wie viele Einträge handelt es hier, dass Cron-Job allein über 1:30 Std. benötigt.

Diese Konstante müssten Cron-Prozess beschleunigen, aber man muss natürlich wissen, welche Ressoursen der Server verfügt:

define('JOBQUEUE_LIMIT_M_EXPORTE', 100000);
define('JOBQUEUE_LIMIT_JOBS', 30);

 

[things4it]

Ich würde eher prüfen wieso dauert der Export so lange. Um wie viele Einträge handelt es hier, dass Cron-Job allein über 1:30 Std. benötigt.

Sind halt an die 170000 Artikel. JOBQUEUE_LIMIT_M_EXPORTE haben wir schon von glaube ich 500 auf 2000 hochgedreht, aber da geht sicher noch mehr.
Das der 1,5 Stunden braucht ist an sich nicht tragisch. Aber ja durch eine Beschleunigung vom Export wäre die Verschiebung nicht so drastisch.

Naja ich belass es mal bei dem dirty fix^^.

Vllt. hat ja jemand von JTL noch eine Info ob das jetzt eher ein Bug oder ob das bewusst so sein soll?
Oder einfach ein Bug- Ticket/Feature-Request erstellen?

 

[things4it]

Also ich habe jetzt das zugehörige issue dazu gefunden: https://issues.jtl-software.de/issues/SHOP-5081

Hätte ich vorher schon finden sollen ... sorry.
Aber ja wäre super wenn das ein paar votes bekommt. Ist ja doch schon etwas älter.