Bonjour, vous attendez de la communauté un support le plus précis et le plus rapide qu'il soit !
Vous débutez avec Maximus, veuillez consulter de prime abord ce fil de discussion, et celui-ci ... De notre coté, nous sommes désireux d'apporter le support le plus adapté qu'il soit à chaque situation ... Pour commencer, avez vous consulté le wiki maximus et/ou les tutoriaux ???
Aussi la solution est simple et applicable rapidement: 1 ) Pour tout nouveau fil de discussion, mettez un titre le plus explicite possible 2 ) Remplissez du plus précisément possible votre mini-fiche 3 ) Pensez qu'une réponse peut être postée plusieures heures voir quelques jours après votre question, il est donc bon de remonter le sujet de temps en temps mais point trop n'en faut :) 4 ) Pensez que Maximus est livré avec le forum bbToMax version 1.0.0 à l'origine, et que vous trouverez la dernière version 1.0.2 de disponible sur www.bbtomax !!! 5 )Vous reconnaissez, en postant sur ce site, avoir pris connaissance du règlement interne ! Nous vous souhaitons une forte réussite dans votre projet par le biais de Maximus CMS.
Inscrit le: Feb 03, 2006 Messages: 2520 29818 points
Lieu de résidence
Sujet du message: ServerLoad VS Query_die Posté le: Ven 03 Aoû, 2007 9:19 pm
Ou comment l'une fait passer l'autre pour un vilain petit canard noir.
Hello.
Tous nous connaissons les célèbres mails concernant la fonction ServerLoad.
Et tous avons incriminés cette fonction prétextant qu'elle mettait le serveur par terre avec son "MySQL server has gone away".
Enfin tous, presque, car j'ai toujours eu des doutes que ce soit cette fonction qui merdoyait. (Epsy en est témoin, je lui est souvent signifié.).
Pourquoi des doutes ?
Tout simplement que lorsque qu'un serveur de BDD ne répond plus, c'est vraiment autrement que cela se passe.
De plus, cette information prise dans son premier sens peut faire penser que le serveur par en brioche mais on oublie aussi que cela peut venir tout simplement d'un script qui dure un temps fou et que le serveur, à force d'attendre, dit "Woh, tu me gonfles" ou tout simplement une fermeture de la BDD.
Et oui.
J'ai toujours cherché le pourquoi du comment, à me prendre la tête comme pas possible.
Tous ceux qui codent connaissent ce hasard à trouver les failles ou les résolutions.
Et ce hasrad, je l'ai eu.
Tout simplement en regardant de plus près le block User_Island.
Je me suis dis que pour mieux voir ce qu'il se passe, je vais utiliser la petite soeur de messages_die, query_die.
Alors, à chaque requête SQL ou appel au fichier MySQL.php, je la mets.
Et quelle surprise, 48 mails rien que la première fois.
Que diantre, m'ouis-je dire.
Pourtant, je ne me suis pas fait ch*** à taper la fonction.
Un bête copié-collé.
Et le plus étonnant, c'est que la première erreur se passe sur les messages privés.
Ben ça y est, la BS pète les plombs.
En fait non.
Voilà la fameuse requête :
Code:
if ( !($result = $GLOBALS['db']->sql_numrows($GLOBALS['db']->sql_query($sql))
{ query_die(MODULE_ERROR, 'Could not SELECT Private_Messages, '', __LINE__, __FILE__, $sql);}
Quand on la regarde comme ceci, elle est identique à beaucoup de lignes figurant dans la BS (comme dans le module statistiques) et ne semble révéler quoique ce soit.
Et pourtant.
La première erreur est l'imbrication des deux fonctions.
La deuxième peut très bien renvoyer null et la première se plante carrément. (Dans l'ordre de lecture.).
Ce qui fait que query_die, du fait d'un traitement d'un message à vide de l'erreur SQL, ne renvoie rien de rien à part les mails.
La deuxième erreur est que cette ligne de code n'empêche pas le script de continuer.
Et le délire commence. Tout s'enchaine. Le incof de la fonction query_die ke doit pas y être étranger (Peux pas vérifier, un coquin a crypté un certain fichier. ). Le script continue et query_die se voit ingurgiter une quantité astronmique d'erreurs à ne pouvoir renseigner dans la BDD, la BS fait des requêtes en veux-tu en voilà pour positionner le reste (A savoir les blocks.) et au final renvoie une quantité de mails signifiant que le serveur ne répond plus cetainement dû à la fermeture de la BDD.
Les solutions s'imposent toutes seules.
De un, ne pas imbriquer les fonctions de MySQL.php, le vide étant permis et n'est pas une erreur.
De deux, arrêter le script. Ce qui donne ceci :
Code:
$sql = "SELECT `privmsgs_to_userid`
FROM `".PRIVMSGS_TABLE."`
WHERE `privmsgs_to_userid`='$num'
AND (`privmsgs_type`='5' OR `privmsgs_type`='1')";
$result = $GLOBALS['db']->sql_query($sql)
or die(query_die(BLOCK_ERROR, "Could not SELECT FROM ".PRIVMSGS_TABLE."", "", __LINE__, __FILE__, $sql));
$mpnuev = $GLOBALS['db']->sql_numrows($result);
A travers ceci, vous renvoyez bien une erreur SQL en cas d'un retour erroné de la requête SELECT et arrêtez le script grâce à l'alias de la fonction exit, die.
Et voilà comment une erreur peut amener à condamner une fonction alors qu'une autre en est la cause.
P.S. : méfiance quand même. J'ai personnellement modifié pas moins de six fichiers du root du Kernel. Sur MC, les modifs apportées à blocks_maximus.php et blocks_phpnuke.php beugguent.
A plus de recherche.
Les fichiers que j'ai modifiés seront transmis à la team pour un débugage total pour ne plus être envahi de ces fameux mails.
N.B. : cette analyse m'est propre bien évidemment et je peux me tromper. Avis à la populasse pour son analyse.
Participez sur nos forums, et retrouvez en lieu et place de la publicité des informations plus précises sur chacun des utilisateurs, identifiez vous dès à présent
Sujet du message: Re: ServerLoad VS Query_die Posté le: Ven 03 Aoû, 2007 9:28 pm
tu a testé ca aussi sur world non?
Participez sur nos forums, et retrouvez en lieu et place de la publicité des informations plus précises sur chacun des utilisateurs, identifiez vous dès à présent
Inscrit le: Feb 03, 2006 Messages: 2520 29818 points
Lieu de résidence
Sujet du message: Re: ServerLoad VS Query_die Posté le: Ven 03 Aoû, 2007 9:32 pm
Hello.
C'est exact.
Sauf que sur Word, j'ai été encore plus violent puisque le code erreur 2006 est ignoré.
Participez sur nos forums, et retrouvez en lieu et place de la publicité des informations plus précises sur chacun des utilisateurs, identifiez vous dès à présent
Sujet du message: Re: ServerLoad VS Query_die Posté le: Ven 03 Aoû, 2007 9:41 pm
eh ben putain
mais bon j'ai plus d'erreur apparemment et le site fonctionne bien
Participez sur nos forums, et retrouvez en lieu et place de la publicité des informations plus précises sur chacun des utilisateurs, identifiez vous dès à présent
Inscrit le: May 12, 2005 Messages: 2961 38387 points
Lieu de résidence
Sujet du message: Re: ServerLoad VS Query_die Posté le: Sam 25 Aoû, 2007 7:04 pm
des avancées ont été faites là dessus?
Participez sur nos forums, et retrouvez en lieu et place de la publicité des informations plus précises sur chacun des utilisateurs, identifiez vous dès à présent
Vous ne pouvez pas poster de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas voter dans les sondages de ce forum Vous ne pouvez pas joindre des fichiers Vous ne pouvez pas télécharger des fichiers
Hebeh.com, hebergement professionnel de sites internet www.hebeh.com
Hicih.com, noms de domaine pour vos sites internet www.hicih.com
Les forums
Accueil
10 derniers posts
Kalender: impossible de se rendre dans la configuration...
29818 points
). Le script continue et query_die se voit ingurgiter une quantité astronmique d'erreurs à ne pouvoir renseigner dans la BDD, la BS fait des requêtes en veux-tu en voilà pour positionner le reste (A savoir les blocks.) et au final renvoie une quantité de mails signifiant que le serveur ne répond plus cetainement dû à la fermeture de la BDD.
