Seite 1 von 2
4.5.2 alpha: Time-Out-Problem
Verfasst: Mo 19. Jul 2004, 17:24
von m.wohlers
Hallo!
Ich nutze den aktuellen Snapshot der Contenido 4.5.2 alpha (contenido-cvs-45-2004-07-16.tar.bz2) und habe folgendes Problem:
bei drei verwalteten Mandanten passiert es in unregelmäßigen Abständen und Situationen, daß vom ausgewählten Mandant in den Standard-Mandent zurückgewechselt wird. Z.B. nach dem Ändern eines Layouts (was einwandfrei funktioniert) sieht man links in der Navigation die Layouts des Standard-Mandanten, obwohl im rechten Frame das aktuelle Layout offen ist. Klickt man dann auf "Vorschau" gibt's Fehler...
Leider kann ich den Bug nicht so reproduzieren, daß daraus eine "Drücke x und es passiert y"-Beschreibung entsteht, aber er tritt häufig auf.
Verfasst: Fr 23. Jul 2004, 07:02
von emergence
meinst du wenn du den 3 mandanten bearbeitest, das er zu den ersten mandanten springt (beim editor allgemein)?
oder tritt das nur bei einer style-layout änderung beim 3 mandanten auf ?
Verfasst: Di 10. Aug 2004, 06:09
von m.wohlers
Hallo Emergence!
emergence hat geschrieben:meinst du wenn du den 3 mandanten bearbeitest, das er zu den ersten mandanten springt (beim editor allgemein)?
oder tritt das nur bei einer style-layout änderung beim 3 mandanten auf ?
Sorry, war wegen Urlaub nicht erreichbar...
Es tritt bei verschiedenen Funktionen auf, daß irgendwie intern zum ersten Mandanten "zurückgewechselt" wird. Wie ich es beschrieben habe, ist im Main-Frame dann zwar wie gewünscht z.B. das Layout vom dritten (eigentlich aktuellen) Mandanten zu sehen, in der Navigation links kommt jedoch die Information vom ersten Mandanten und bei der nächsten Aktion kommt dann ein Fehler, da sich Contenido nicht mehr auskennt...
Verfasst: Di 10. Aug 2004, 12:31
von timo
Gibts eine "Anleitung", wie man das nachvollziehen kann?
Verfasst: Mi 11. Aug 2004, 13:12
von m.wohlers
Hallo Timo!
timo hat geschrieben:Gibts eine "Anleitung", wie man das nachvollziehen kann?
Ich hatte gehofft, daß meine Darstellung bildlich genug war... aber noch ein Versuch:
Ich habe drei Mandanten eingerichtet. Ich gehe in's Backend von Contenido und wähle dort z.B. den dritten Mandanten aus, um dort zu arbeiten.
Dann gehe ich in "Style -> Layouts" und wähle dort ein Layout aus. Wenn ich jetzt im RECHTEN Frame Änderungen am Layout durchführe und den grünen "Änderungen speichern"-Button drücke, dann werden die Änderungen ordnungsgemäß gespeichert. Allerdings erscheinen danach in dem LINKEN Frame mit der Liste an vorhandenen Layouts diejenigen für Mandant 1, und im RECHTEN Frame sehe ich das zuletzt bearbeitete Layout aus Mandant 3.
Irgendwie wurde also NACH dem Bearbeiten des Layouts in den Mandant 1 zurückgesprungen. Wenn ich versuche, weiterzuarbeiten, erhalte ich Fehler und muß also manuell wieder auf Mandant 3 umwechseln. Das taucht sporadisch auf, ich kann keine Regelmäßigkeit erkennen, pro Stunde aber sicher 3-4 mal bei meinem Produktiveinsatz. Einträge im ErrorLog gibt es keine.
Ich werde demnächst auf den aktuellen Snapshot "contenido-cvs-2004-08-10" wechseln, vielleicht habe ich da anderes Verhalten, das werde ich prüfen und ggf. hier posten.
Für weitere Fragen... her damit!
Verfasst: Sa 14. Aug 2004, 13:10
von m.wohlers
Hallo Timo!
Also, auch mit dem brandneuen Snapshot (contenido-cvs-2004-08-13.tar.bz2) hat sich nichts am Verhalten geändert.
Mein Vorgang, der soeben zum beschriebenen Fehler führte: Änderungen an einem Modul gemacht, anschließend auf "Content -> Artikel" gewechselt - und der Kategorie-Baum erschien leer. Im "MyContenido" war wieder zu sehen, daß Mandant Nr. 1 aktiv war - obwohl ich vorher im dritten Mandanten aktiv war.
Falls es von Belang ist:
Code: Alles auswählen
Anzahl Benutzer 3
Anzahl der Artikel 42
Server operating system Apache/1.3.31 (Unix) FrontPage/5.0.2.2635 PHP/4.3.8
MySQL Serverversion 4.0.20-log
Installierte PHP-Version 4.3.8
safe_mode deactivated
magic_quotes_gpc Aktiviert
magic_quotes_runtime deactivated
gpc_order GPC
memory_limit 16M
max_execution_time 30
Deaktivierte Funktionen nothing disabled
Gettext extension geladen
sql.safe_mode deactivated
GD library Einstellungen Werte
GD Support enabled
GD Version bundled (2.0.23 compatible)
FreeType Support enabled
FreeType Linkage with freetype
GIF Read Support enabled
JPG Support enabled
PNG Support enabled
WBMP Support enabled
XBM Support enabled
include_path ./:/usr/share/pear/
Any ideas?
Verfasst: Fr 14. Jan 2005, 18:49
von timo
Nein leider nicht...das Phänomän haben wir mittlerweile auch, aber niemand weiß, wo es herkommt...vor allem, weil es scheinbar "zufällig" auftritt
Verfasst: Sa 15. Jan 2005, 10:14
von m.wohlers
Hallo timo!
timo hat geschrieben:Nein leider nicht...das Phänomän haben wir mittlerweile auch, aber niemand weiß, wo es herkommt...vor allem, weil es scheinbar "zufällig" auftritt
Aber Ihr könnt es auch beobachten, oder? Sorry daß ich frage, aber manchmal fühlt man sich wie im falschen Film, wenn alle sagen "also hier können wir das nicht nachvollziehen"
Verfasst: Mi 19. Jan 2005, 16:20
von timo
ja woher das kommt weiß niemand, und auch nicht, wie man es reproduzieren kann...
Verfasst: Mo 7. Feb 2005, 18:24
von timo
Ich glaube, wir haben das ganze jetzt gefunden
Allerdings eher durch Zufall....hier die Lösung:
Mandantenwechsel-Bug
--------------------
Bugbeschreibung
Der Bug entsteht durch eine Verkettung von Ereignissen. Zum einen wird in einem fehlerhaften Cronjob (send_reminder.php) der Wert für den aktuellen Mandanten gesichert, aber noch bevor dieser aus dem globalen Kontext initialisiert wurde (=ein nichtgesetzter Wert wird gespeichert). Am Ende des Cronjobs wird der gespeicherte Wert zurückgesichert, der dann jedoch immer noch leer ist. Im Regelfalle bleibt das Problem unbemerkt, wenn die Cronjobs schnell genug durchlaufen (sie werden nur im Frame 1 im Backend ausgeführt) und eine andere Seite nach Frame 1 seine Daten in die Session sichert (das wechseln des Mandanten betrifft dann nur Frame 1, welches in den meisten Fällen unbemerkt bleibt).
Benötigt aber der Cronjob, der in Frame 1 getriggert wurde, länger als alle anderen Cronjobs, so werden die Session-Daten von Frame 1 auch in die Datenbank gesichert und überschreiben damit den Mandanten, welches sich allerdings erst beim nächsten Laden einer Backend-Seite auswirkt.
Lösung
Die Lösung ist einerseits ein Patch im Cronjob "send_reminder.php", als auch in der Sicherstellung, daß globale Systemvariablen nicht durch cronjobs überschrieben werden können. Änderung in der send_reminder.php:
wird zu
In der pseudo-cron.inc.php wird
Code: Alles auswählen
chdir($PC_jobDir);
$PC_jobs = parseCronFile($PC_cronTab, $PC_debug);
for ($i=0;$i<count($PC_jobs);$i++) {
runJob($PC_jobs[$i], $PC_jobDir, $PC_writeDir, $PC_useLog, $PC_debug);
}
$PC_jobs = parseCronFile($PC_localCronTab, $PC_debug);
for ($i=0;$i<count($PC_jobs);$i++) {
runJob($PC_jobs[$i], $PC_jobDir, $PC_writeDir, $PC_useLog, $PC_debug);
}
zu
Code: Alles auswählen
$bJobRunned = false;
chdir($PC_jobDir);
$PC_jobs = parseCronFile($PC_cronTab, $PC_debug);
for ($i=0;$i<count($PC_jobs);$i++) {
$bJobRunned = true;
runJob($PC_jobs[$i], $PC_jobDir, $PC_writeDir, $PC_useLog, $PC_debug);
}
$PC_jobs = parseCronFile($PC_localCronTab, $PC_debug);
for ($i=0;$i<count($PC_jobs);$i++) {
$bJobRunned = true;
runJob($PC_jobs[$i], $PC_jobDir, $PC_writeDir, $PC_useLog, $PC_debug);
}
In der main.php wird
Code: Alles auswählen
if ($frame == 1)
{
$oldpwd = getcwd();
chdir($cfg["path"]["contenido"].$cfg["path"]["cronjobs"]);
cInclude("includes", "pseudo-cron.inc.php");
chdir($oldpwd);
}
zu
Code: Alles auswählen
if ($frame == 1)
{
$oldpwd = getcwd();
chdir($cfg["path"]["contenido"].$cfg["path"]["cronjobs"]);
cInclude("includes", "pseudo-cron.inc.php");
chdir($oldpwd);
if ($bJobRunned == true)
{
/* Some cronjobs might overwrite important system variables.
* We are thaw'ing the session again to re-register these variables.
*/
$sess->thaw();
}
}
Verfasst: Di 8. Feb 2005, 18:24
von m.wohlers
Hallo timo!
timo hat geschrieben:Ich glaube, wir haben das ganze jetzt gefunden
Allerdings eher durch Zufall....hier die Lösung:
Mandantenwechsel-Bug
--------------------
Ich liebe Euch alle...
Fast zu schön, um wahr zu sein, aber zu einfallslos für einen Faschingscherz...
Sollte ja dann im nächsten Snapshot drinnen sein, oder? Gibt es am Freitag wieder einen aus dem (neuen) CVS oder dauert das noch länger?
Fröhliche Grüsse aus dem verschneiten Oberbayern...
Verfasst: Di 8. Feb 2005, 18:50
von timo
m.wohlers hat geschrieben:Ich liebe Euch alle...
Fast zu schön, um wahr zu sein, aber zu einfallslos für einen Faschingscherz...
Wenn es ein Scherz wäre, hätte ich bestimmt nicht gestern "Hab ich dich du scheiss-Bug" hier im Büro herumgebrüllt
Sollte ja dann im nächsten Snapshot drinnen sein, oder? Gibt es am Freitag wieder einen aus dem (neuen) CVS oder dauert das noch länger?
Ausnahmsweise gibts den schon morgen, aber danach wieder wöchentlich.
Verfasst: Di 8. Feb 2005, 18:59
von m.wohlers
Hi timo!
timo hat geschrieben:m.wohlers hat geschrieben:Ich liebe Euch alle...
Fast zu schön, um wahr zu sein, aber zu einfallslos für einen Faschingscherz...
Wenn es ein Scherz wäre, hätte ich bestimmt nicht gestern "Hab ich dich du scheiss-Bug" hier im Büro herumgebrüllt
Gibt es eine Webcam aus Deinem Büro? Wenn nein, bitte unbedingt installieren, ist fast so wichtig wie die wöchentlichen Snapshots
Sollte ja dann im nächsten Snapshot drinnen sein, oder? Gibt es am Freitag wieder einen aus dem (neuen) CVS oder dauert das noch länger?
Ausnahmsweise gibts den schon morgen, aber danach wieder wöchentlich.
Thx... heute Abend? morgen Abend? Anyway, ich schau's mir an...
Grüsse...
Verfasst: Di 8. Feb 2005, 19:04
von timo
m.wohlers hat geschrieben:Thx... heute Abend? morgen Abend? Anyway, ich schau's mir an...
Also rein technisch gesehen wird der Snapshot um 23 Uhr erzeugt, je nachdem, wie lange der Server braucht, liegt er dann entweder heute (vor 0 Uhr) oder morgen (nach 0 Uhr) vor
Verfasst: Di 8. Feb 2005, 19:56
von emergence
um nur kurz auf den bug zurück zu kommen
wie wäre es mit der option zu beginn des cronjobs alle variablen zu sichern mittels
$sess->freeze();
und anschließend nach den cronjobs mittels
$sess->thaw();
wieder neu zu laden... (so wie du es oben bereits machst)
sollte eventuell ja auch funktionieren...
dann sollte es ziemlich egal sein welche variablen der cronjob ändert...