0.9 beta: Fehler bei Netzwerk und Storage

ThH

Haaaaaloooo….

Ich weiß Ihr seid alle schwer beschäftigt, aber ich kann mit meinen oben beschriebenen Fehlern nicht wirklich weiter testen. Habt Ihr vielleicht eine Idee was das sein könnte?

Danke ThH

npotthast

Hast du denn mal eine 4-er mySQL Version getestet? Es sollte eigentlich auch unter mySQL 5 keine Probleme bereiten, wir haben i-doIT aber nicht eingehend getestet unter dieser Version.
Wir konnten deinen Fehler bisher auch leider nicht reproduzieren, sonst könnten wir dir sicher schneller weiter helfen.

ThH

Hallo,

hab die beta jetzt nochmal neu installiert und eine MySQL 4.1.20 auf einem anderen Server (sollte ja kein Problem sein) verwendet. An dem oben beschriebenen Verhalten hat sich kleider nichts geändert. Bekomme nachwievor diese Backtrace-Meldungen wenn ich auf bestimmt Sachen klicke.

Vielleicht habt Ihr ja doch noch eine idee.

Gruß ThH

Guest

Hi TnH,

wahrscheinlich ist 65535 noch zu lang für einen VARCHAR, dem Datentyp, in dem Strings gespeichert werden. Tausch bitte mal in Niclas' Code-Patch die 65535 durch 256 aus. Ich hoffe, dann geht's wieder.

@npotthast:

So, danke erstmal, dass du dir selber soviel Mühe gemacht hast. Dafür habe ich hier auch ein kleines Stückchen Quellcode für dirch, den du in der Datei "src\classes\components\isys_component_list.class.php" austauschen kannst. Entweder dies, oder du wartest auf das nächste Update, welches bald kommen müsste (ich weiss nicht genau wann, falls du fragen würdest). Die Änderung kommt ungefähr in Zeile 245:
case "string":
	if ($len < 65535) {
		$type = "VARCHAR";
	} else {
		$type = "TEXT";
		$len = "";
	}
	break;
Im Prinzip wird durch die Änderung verhindert, dass ein zu großer VARCHAR angelegt wird. Das sollte das Problem schnell lösen. Berichte doch bitte, ob dies geholfen hat. Benutzt du die mySQL Version von unserem Installer oder eine andere?

ThH

Hallo aw,

hab es mit dem kleineren Wert getestet. Auch damit geht der Fehler leider nicht weg.

Ich möchte nochmal auf meinen Post vom 17.07. verweisen. Der MySQL-Fehler aus meinem ersten Post, ist mit der Änderung der Datensatzlänge auf 65535 behoben. Jetzt geht es nur noch um dieses komische "Backtrace", was ich auch in dem Eintrag vom 17.07 gepostet habe. Könnt Ihr nicht aus dem Backtrace selbst den Ursprung des Fehlers ermitteln? Ich vermute mal, dass diese Funktion aus genau diesem Grund einprogrammiert wurde.

Ich habe mal ein kleines animiertes Gif an diesen Post angehängt um Euch hoffentlich besser verdeutlichen zu können, was bei mir wann passiert. Interessant ist zum Beispiel, dass wenn ich im Menü auf "Port" klicke, ich den Fehler bekomme (siehe Bild 7 und 8 ), klicke ich jedoch bei einem Interface auf "Ports anzeigen" wird die Seite mit den Ports sauber angezeigt (siehe Bild 9 und 10). Gibt es vielleicht Probleme mit Übergabeparametern im Query? Beide Querys unterscheiden sich auch:

URL bei Klick auf "Port" im Menü:

http://<serveradresse>/i-doit/index.php?viewMode=1002&tvMode=1006&objID=4&objGroupID=2%3FPHPSESSID%3D76052d5a79fd6751d55449d2012d5eae&objTypeID=6%3FPHPSESSID%3D76052d5a79fd6751d55449d2012d5eae&catMenuSelection=3&catListView=1&catgID=7?PHPSESSID=76052d5a79fd6751d55449d2012d5eae

URL bei Klick auf "Ports anzeigen" in der Interface-Liste:

http://<serveradresse>/i-doit/index.php?viewMode=1002&tvMode=1006&objID=4&objTypeID=6?PHPSESSID=76052d5a79fd6751d55449d2012d5eae&catgID=7&catMenuSelection=3&catListView=1&ifaceID=4&

Vielleicht könnt Ihr ja mit diesen zusätzlichen Informationen noch ein wenig mehr anfangen.

Danke ThH

</serveradresse></serveradresse>

ThH

Hallo,

ich weiß Ihr habt viel zu tun und neben diesem auch noch andere Projekte, aber ich würde mich wirklich freuen, wenn sich nochmal jemand meines Problemes annehmen könnte.

Danke ThH

npotthast

Hi ThH,

sorry, dass es so lange gedauert hat, aber wie du schon erwähnt hattest, wir haben ne Menge zu tun. Was mir gerade auffällt, ist dass bei deinen 2 Links weiter oben (z.B. …/index.php?viewMode=1002&tvMode=1006&objID=4&objGroupID=2%3FPHPSESSID%3D76052d5a79fd6751d55449d2012d5eae&objTypeID=6%3FPHPSESSID%3D76052d5a79fd6751d55449d2012d5eae&catMenuSelection=3&catListView=1&catgID=7?PHPSESSID=76052d5a79fd6751d55449d2012d5eae)
die PHP Session ID untergebracht ist, und das mehrmals. Das ist eigentlich nicht das normale Verhalten, was ich erwarten würde. Kannst du das mal in den Einstellungen überprüfen?

ThH

Hallo,

Habe folgenden Fehler jetzt auch in der Version 0.9 wieder:

isys_exception_database : Query error: 'CREATE TABLE tempObjList_e128p43rlh79v9vrfr8o50jpa7 (isys_catg_stor_list__id BIGINT, isys_catg_stor_list__isys_stor_manufacturer__id BIGINT, isys_catg_stor_list__isys_stor_model__id BIGINT, isys_catg_stor_list__id__raid_pool BIGINT, isys_catg_stor_list__isys_stor_raid_level__id BIGINT, isys_catg_stor_list__isys_catg_controller_list__id BIGINT, isys_catg_stor_list__isys_catd_sanpool_list__id BIGINT, isys_catg_stor_list__isys_stor_con_type__id BIGINT, isys_catg_stor_list__isys_catg_stor__id BIGINT, isys_catg_stor_list__isys_stor_unit__id BIGINT, isys_catg_stor_list__isys_stor_type__id BIGINT, isys_catg_stor_list__title VARCHAR (255), isys_catg_stor_list__description VARCHAR (21845), isys_catg_stor_list__capacity BIGINT, isys_catg_stor_list__status BIGINT, isys_catg_stor_list__property BIGINT, isys_catg_stor_list__hotspare BIGINT, isys_stor_type__id BIGINT, isys_stor_type__title VARCHAR (255), isys_stor_type__description VARCHAR (21845), isys_stor_type__const VARCHAR (255), isys_stor_type__sort BIGINT, isys_stor_type__property BIGINT, isys_stor_type__status BIGINT, isys_stor_unit__id BIGINT, isys_stor_unit__title VARCHAR (255), isys_stor_unit__description VARCHAR (21845), isys_stor_unit__const VARCHAR (255), isys_stor_unit__sort BIGINT, isys_stor_unit__byte BIGINT, isys_stor_unit__status BIGINT, isys_stor_unit__property BIGINT, isys_stor_con_type__id BIGINT, isys_stor_con_type__title VARCHAR (255), isys_stor_con_type__description VARCHAR (21845), isys_stor_con_type__sort BIGINT, isys_stor_con_type__const VARCHAR (255), isys_stor_con_type__status BIGINT, isys_stor_con_type__property BIGINT, isys_catg_controller_list__id BIGINT, isys_catg_controller_list__isys_controller_manufacturer__id BIGINT, isys_catg_controller_list__isys_controller_model__id BIGINT, isys_catg_controller_list__isys_catg_controller__id BIGINT, isys_catg_controller_list__isys_controller_type__id BIGINT, isys_catg_controller_list__title VARCHAR (255), isys_catg_controller_list__description VARCHAR (21845), isys_catg_controller_list__portcount BIGINT, isys_catg_controller_list__status BIGINT, isys_catg_controller_list__property BIGINT, isys_stor_raid_level__id BIGINT, isys_stor_raid_level__title VARCHAR (255), isys_stor_raid_level__description VARCHAR (21845), isys_stor_raid_level__const VARCHAR (255), isys_stor_raid_level__sort BIGINT, isys_stor_raid_level__property BIGINT, isys_stor_raid_level__status BIGINT, isys_catd_sanpool_list__id BIGINT, isys_catd_sanpool_list__isys_stor_unit__id BIGINT, isys_catd_sanpool_list__isys_catd_sanpool__id BIGINT, isys_catd_sanpool_list__title VARCHAR (255), isys_catd_sanpool_list__description VARCHAR (21845), isys_catd_sanpool_list__capacity BIGINT, isys_catd_sanpool_list__status BIGINT, isys_catd_sanpool_list__property BIGINT, isys_catg_stor__id BIGINT);': Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. You have to change some columns to TEXT or BLOBs (Extended Information: array ( 'server' => '5.0.18', 'host' => '127.0.0.1 via TCP/IP', 'client' => '5.0.18', 'proto' => 10, ))
VIEW HANDLER:
Backtrace: #0 _get_backtrace() called at [/srv/www/htdocs/i-doit/src/classes/modules/isys_module_cmdb.class.php:523] #1 isys_module_cmdb->start() called at [/srv/www/htdocs/i-doit/src/classes/modules/isys_module_manager.class.php:268] #2 isys_module_manager->load(2) called at [/srv/www/htdocs/i-doit/src/i-doit.inc.php:125] #3 include_once(/srv/www/htdocs/i-doit/src/i-doit.inc.php) called at [/srv/www/htdocs/i-doit/src/hypergate.inc.php:173] #4 include_once(/srv/www/htdocs/i-doit/src/hypergate.inc.php) called at [/srv/www/htdocs/i-doit/index.php:339]
isys_exception_dao : DAO Exception: Running transaction has been canceled. Could not isys_component_dao::update() : CREATE TABLE tempObjList_e128p43rlh79v9vrfr8o50jpa7 (isys_catg_stor_list__id BIGINT, isys_catg_stor_list__isys_stor_manufacturer__id BIGINT, isys_catg_stor_list__isys_stor_model__id BIGINT, isys_catg_stor_list__id__raid_pool BIGINT, isys_catg_stor_list__isys_stor_raid_level__id BIGINT, isys_catg_stor_list__isys_catg_controller_list__id BIGINT, isys_catg_stor_list__isys_catd_sanpool_list__id BIGINT, isys_catg_stor_list__isys_stor_con_type__id BIGINT, isys_catg_stor_list__isys_catg_stor__id BIGINT, isys_catg_stor_list__isys_stor_unit__id BIGINT, isys_catg_stor_list__isys_stor_type__id BIGINT, isys_catg_stor_list__title VARCHAR (255), isys_catg_stor_list__description VARCHAR (21845), isys_catg_stor_list__capacity BIGINT, isys_catg_stor_list__status BIGINT, isys_catg_stor_list__property BIGINT, isys_catg_stor_list__hotspare BIGINT, isys_stor_type__id BIGINT, isys_stor_type__title VARCHAR (255), isys_stor_type__description VARCHAR (21845), isys_stor_type__const VARCHAR (255), isys_stor_type__sort BIGINT, isys_stor_type__property BIGINT, isys_stor_type__status BIGINT, isys_stor_unit__id BIGINT, isys_stor_unit__title VARCHAR (255), isys_stor_unit__description VARCHAR (21845), isys_stor_unit__const VARCHAR (255), isys_stor_unit__sort BIGINT, isys_stor_unit__byte BIGINT, isys_stor_unit__status BIGINT, isys_stor_unit__property BIGINT, isys_stor_con_type__id BIGINT, isys_stor_con_type__title VARCHAR (255), isys_stor_con_type__description VARCHAR (21845), isys_stor_con_type__sort BIGINT, isys_stor_con_type__const VARCHAR (255), isys_stor_con_type__status BIGINT, isys_stor_con_type__property BIGINT, isys_catg_controller_list__id BIGINT, isys_catg_controller_list__isys_controller_manufacturer__id BIGINT, isys_catg_controller_list__isys_controller_model__id BIGINT, isys_catg_controller_list__isys_catg_controller__id BIGINT, isys_catg_controller_list__isys_controller_type__id BIGINT, isys_catg_controller_list__title VARCHAR (255), isys_catg_controller_list__description VARCHAR (21845), isys_catg_controller_list__portcount BIGINT, isys_catg_controller_list__status BIGINT, isys_catg_controller_list__property BIGINT, isys_stor_raid_level__id BIGINT, isys_stor_raid_level__title VARCHAR (255), isys_stor_raid_level__description VARCHAR (21845), isys_stor_raid_level__const VARCHAR (255), isys_stor_raid_level__sort BIGINT, isys_stor_raid_level__property BIGINT, isys_stor_raid_level__status BIGINT, isys_catd_sanpool_list__id BIGINT, isys_catd_sanpool_list__isys_stor_unit__id BIGINT, isys_catd_sanpool_list__isys_catd_sanpool__id BIGINT, isys_catd_sanpool_list__title VARCHAR (255), isys_catd_sanpool_list__description VARCHAR (21845), isys_catd_sanpool_list__capacity BIGINT, isys_catd_sanpool_list__status BIGINT, isys_catd_sanpool_list__property BIGINT, isys_catg_stor__id BIGINT); (Extended Information: 0)

Wie ich in der Datei "src\classes\components\isys_component_list.class.php" sehe, habt Ihr die Änderung die mir npotthast damals vorgeschlagen hatte, inzwischen ins Release übernommen. Damit sieht es so aus, also ob die "< 63535" noch zu groß sind. Habe nun, wie von aw vorgeschlagen, den Wert auf 256 geändert. Danach bekomme ich keine Fehlermeldung mehr.

Es wäre also nicht verkehrt, wenn Ihr mit dem nächsten Update eine korrigierte Version ausliefern könntet:


case "string":
        if ($len < 256) {
                $type = "VARCHAR";
        } else {
                $type = "TEXT";
                $len = "";
        }
        break;

Grüße ThH

npotthast

Welche genaue mySQL Version ist es denn jetzt gewesen?
Übrigens schon einmal danke für deine ganze Mühe, es freut einen sehr wenn alle mitarbeiten

ThH

MySQL: 5.0.18

npotthast

Wir testen das mal durch damit, auch wenn ich am liebsten fragen würde, ob du mal eine andere Version testen könntest. Ich werde aber noch die genaueren Testergebnisse an dieser Stelle bekannt geben.

ThH

@ThH:

Wie ich in der Datei "src\classes\components\isys_component_list.class.php" sehe, habt Ihr die Änderung die mir npotthast damals vorgeschlagen hatte, inzwischen ins Release übernommen. Damit sieht es so aus, also ob die "< 63535" noch zu groß sind. Habe nun, wie von aw vorgeschlagen, den Wert auf 256 geändert. Danach bekomme ich keine Fehlermeldung mehr.

Es wäre also nicht verkehrt, wenn Ihr mit dem nächsten Update eine korrigierte Version ausliefern könntet:
case "string":
        if ($len < 256) {
                $type = "VARCHAR";
        } else {
                $type = "TEXT";
                $len = "";
        }
        break;
Grüße ThH

Habe den Patch 0.9.1 installiert. Leider sind die o.g. Fehler danach wieder aufgetreten. Konnte mich zum Glück noch an diesen Thread hier und die Lösung erinnern und habe den Code wieder angepasst.

Ich weiß, dass MySQL 5 derzeit nicht offiziell unterstützt wird, aber bei mir läuft i-doit super mit MySQL 5 (bis auf diesen kleinen Fehler hier), also wieso übernehmt Ihr die Code-Anderung nicht einfach mit in das nächste Release/Patch. Die Code-Änderung kommt ja auch nicht von mir, sondern von aw.

Ich hab auch kein Problem damit, die Änderung jedes mal von neuem zu machen. Es nervt nur halt.

Gruß ThH