search

Inxmail / inx_magento1

Inxmail Professional Email Marketing für Magento CE und EE (1.x)
0 stars 0 forks source link

Inxmail eigene Cronjobs von den Magento-Cronjobs trennen um Seiteneffekte zu verhindern [INX-21] #27

Closed falco-knapp closed 8 years ago

falco-knapp commented 8 years ago

Problembeschreibung

Die Cronjobs in Magento zur Synchronisation der Daten mit Inxmail dauern u.U. sehr lange. Dies führt dazu, dass bei Kunden andere wichtige Cronjobs u.U. nur stark verzögert ausgeführt oder sogar ganz übersprungen werden.

Aufgabe

falco-knapp commented 8 years ago

Hallo Björn,

könnt Ihr bitte evaluieren was der Aufwand für diesen Fix wäre? Wahrscheinlich muss dies noch für Version 3.1.0.6 gemacht werden.

Herzlichen Dank und Gruß,

Falco

falco-knapp commented 8 years ago

Ein Hotfix Patch ist nicht notwendig.

BrocksiNet commented 8 years ago

Haben wir hier erledigt: 10cde95df7cb0ea52edb924d45df58c29e8b41ab

Folgende Zusätzliche Info: Wir haben den Inxmail-Cron aus dem Magento-Cron entfernt. Es wird also nichts synchronosiert wenn KEINE Crontabs angelegt wurden.

Das heißt diese Cronjobs müssen hinzugefügt werden: 0 * * * * [path_to_magento_folder]/shell/dndinxmail/synchronizeUnsubscribed.php 0 1 * * * [path_to_magento_folder]/shell/dndinxmail/synchronizeCustomerGroup.php

Achtung das könnte bei Kunden welche nicht per Shell auf den Server kommen ein Problem sein. Gibt es davon viele? Falls ja sollten wir ggf. die Cron's drin lassen und diese über eine Konfiguration an/aus schalten? Bitte um Feedback. Danke.

falco-knapp commented 8 years ago

Hi Björn,

ich verstehe die 2 Varianten nicht so wirklich. Ist die Alternative nicht genau das, was aktuell implementiert ist? Die Cronjobs können per Konfig ja aktuell schon ein-/ausgeschaltet werden - das würde uns aber nicht wirklich weiterbringen.

Über die Systemumgebung und Rahmenbedingungen der Kunden kann ich leider nicht wirklich etwas sagen. Ist dass denn im Magento-Umfeld oft der Fall, dass solche Einstellungen nicht vorgenommen werden können? Wenn ja, dann ist das wahrscheinlich auch nicht die richtige Lösung für das Problem.

Danke und Gruß,

Falco

falco-knapp commented 8 years ago

Protokoll in Bezug zum Vorgehen aus Slack:

Björn Meyer [10:13 AM] falco habe gerade nochmal mit dem entwickler geredet. also wir sind der meinung das magento kunden einen individuellen cron auf ihrem server einrichten können sollten. wenn ein kunde keinen zugriff auf seinen server hat um das einzurichten dann ist er wahrscheinlich bei einem managed hoster und damit sowieso falsch. wir tendieren also dazu die inxmail-crons aus dem magento cron zu lassen.

Falco Knapp [10:14 AM] ok für mich. Die Einstellungen bleiben aber im BE so bestehen wie bisher, nur dass quasi andere Prozesse den cron ausführen?

Björn Meyer [10:17 AM] wir könnten was den cron angeht aber auch um kleine projekte abzudecken eine zusätzliche config machen die den inxmail-cron für den magento-cron aktiviert. dann hätten wir alle abgeholt und sichergestellt das inxmail erstmal nicht magento blockiert. außer der kunde schaltet es bewusst ein.

​[10:17] sollen wir das noch tun bevor wir 3.1.0.6 fertig machen?

​[10:17] könnte dann dort noch rein

Falco Knapp [10:20 AM] ich würde es erstmal nicht machen - finde das bringt recht viel Komplexität und Erklärungsnotwendigkeit mit sich

Björn Meyer [10:24 AM] Hmmm also ich denke das gerade genau anders. Wenn wir es entfernen wird es wohl erstmal Fragen geben. Und jeder muss wissen wie er einen Cron dafür anlegt. Von daher tendiere ich doch dazu es rein zu nehmen. Es ist auch eher eine Kleinigkeit für uns.

Falco Knapp [10:32 AM] ok, ich vertraue Eurer Einschätzung

Falco Knapp [10:33 AM] dann muss es so sein, dass es sich für Bestandskunden nicht ändert und das herauslösen optional ist

Michael Türk [10:34 AM] ja, optional und durchaus empfohlen, aber einstellbar

falco-knapp commented 8 years ago

Hallo Björn,

ich benötige Informationen darüber was zu tun ist um die Cronjobs unabhängig von den Standard-Magento Crons laufen zu lassen.

Danke und Gruß,

Falco

BrocksiNet commented 8 years ago

Hallo Falco,

hier ein "grundsätzlicher" Link zu CronJobs unter Linux auf Deutsch: https://www.stetic.com/developer/cronjob-linux-tutorial-und-crontab-syntax.html

Für euch müssen also im Crontab die folgenden Jobs angelegt werden:

0 * * * * [path_to_magento_folder]/shell/dndinxmail/synchronizeUnsubscribed.php
0 1 * * * [path_to_magento_folder]/shell/dndinxmail/synchronizeCustomerGroup.php

Wenn ein Cronjob für einen speziellen User angelegt werden soll dann wäre der Befehl zum Beispiel so: crontab -e -u www-data

Und dann das von oben mit dem Pfad zu Magento am Ende rein kopieren.

Das könnte dann so auf einem Live-System aussehen (im Crontab):

# Inxmail Cronjobs
0 * * * * /var/www/live/htdocs/shell/dndinxmail/synchronizeUnsubscribed.php
0 1 * * * /var/www/live/htdocs/shell/dndinxmail/synchronizeCustomerGroup.php

Brauchst du noch mehr Infos oder passt es damit?

Grüße Björn

BrocksiNet commented 8 years ago

Der Kunde kann über das Modul: https://github.com/AOEpeople/Aoe_Scheduler individuelle Magento Cronjobs deaktivieren (also auch die Inxmail Cronjobs).

falco-knapp commented 8 years ago

Nach Rücksprache:

  1. Aoe_Scheduler muss genutzt werden, um die zwei Cronjobs zu deaktivieren. Es reicht nicht, diese per config im Backoffice auszuschalten - da beobachtet werden konnte, dass diese unter gewissen Umständen dennoch ausgeführt werden.
  2. Das herauslösen der Cronjobs in einen eigenen Prozess funktioniert nur durch das setzen der Crontab wie oben beschrieben.
  3. Es ist derzeit nicht vorgesehen, dass die alternative Ausführung der Cronjobs im Backend konfiguriert werden kann.
falco-knapp commented 8 years ago

Der synchronizeUnsubscribed.php Job scheint korrekt zu funktionieren.

Fehler: Der synchronizeCustomerGroup.php Aufruf scheint nicht korrekt zu funktionieren. Es wird zwar eine Gruppe angelegt in Inxmail, aber kein Empfänger hinzugefügt. Im Logfile habe ich folgendes gesehen:

synchronizecustomergroup_exception.log: 2015-11-24T13:20:03+00:00 DEBUG (7): ## EXCEPTION 1783082541 ## 2015-11-24T13:20:03+00:00 DEBUG (7): suscription attribute from list: Magento Customer Group General 2015-11-24T13:20:03+00:00 DEBUG (7): ## / EXCEPTION 1783082541 ##

Erst beim 2. Lauf werden dann die weiteren Gruppen angelegt und der Empänger in die entsprechende Gruppe eingetragen.

Bei der manuelle Synchronisation wird nur die Gruppe in der der Empfänger sich befindet in Inxmail erstellt und der Empfänger in diese eingetragen. Beim alten Cronjob werden alle Gruppen in Inxmail angelegt die gemappt sind und der Empfänger wird korrekt in die richtige Gruppe geschrieben.

BrocksiNet commented 8 years ago

Wir schauen nach dem Problem.

BrocksiNet commented 8 years ago

Es gab einen Fehler bei neuen neu angelegten Gruppen. Es wurden erst die alten Gruppen geholt und dann das Objekt erstellt. Und dann wurden die neuen Gruppen erstellt aber nicht dem Objekt hinzugefügt. Korrektur ist in diesem Commit zu sehen: 3fd42df9dc7b78f8f65d37a06b0970aaa1f72777

falco-knapp commented 8 years ago

Ok, Danke.

Ich bräuchte jetzt eine neue Version des Package damit ich die ganzen Korrekturen Testen kann.

Vielen Dank und Gruß,

Falco

falco-knapp commented 8 years ago

Ich konnte die bestehenden Cronjobs bis auf die in #29 dargestellten Artefakte ausschalten:

  1. Indem der Cronjob zuerst aktiviert wird -> speichern und anschließend wieder deaktiviert wird -> speichern. Dadurch wird die Cronexpression gelöscht und scheinbar der Cronjob nicht mehr ausgeführt.
  2. Mit AOE-Schedular den Cronjob selbst komplett deaktivieren.

Daraufhin habe ich die crontab um folgende Befehle erweitert:

0 * * * * php -f /var/www/html/magento/shell/dndinxmail/synchronizeUnsubscribed.php
0 1 * * * php -f /var/www/html/magento/shell/dndinxmail/synchronizeCustomerGroup.php

und getestet. Die Resultate waren inklusive der bekannten Fehler wie erwartet.