| |  |
| Sauvez un arbre, mangez un castor |
jeudi 11 mars 2010 |
| lundi 12 janvier 2009 |
| 12:11 » Réinstaller IIS sous Vista - programmation, Asp.net |
Pendant presque tout 2008, le serveur web de ma machine de développement (IIS) a refusé de conserver normalement les variables session. Elles étaient gardées en mémoire une fois sur sept et pour un temps indéterminé, ce qui a rendu les tests très laborieux et nerveusement éprouvants (essayer de se logguer sans succès 15 fois de suite pour tester un ajustement cosmétique merdique à 19h30 un vendredi soir, ça rend dingue >_<).
J'ai bien essayé de désinstaller/réinstaller IIS afin d'avoir quelque chose de propre, mais le fait que je retrouve ma configuration précédente après une réinstallation me laissait à penser que l'opération de désinstallation n'avais pas été effectuée correctement. Et j'avais raison, car il y a un ordre de désinstallation ! (vous ne rêvez pas, on est bien en 2009 sur un OS récent ¬_¬)
Une fois la désinstallation/réinstallation effectuée correctement, je me suis retrouvé avec un IIS tout nu que j'ai pu reconfigurer vite fait pour constater que la session fonctionnait correctement, viva, uhohoï ! \0/
Les coupables.
L'ordre adéquat m'a été suggéré par cette page, dont voici la traduction :- Tout désinstaller dans le groupe "Services World Wide Web Services".
- Tout désinstaller dans le groupe "Outils d'administration Web".
- Tout désinstaller dans le groupe "Service d'activation des processus Windows".
- Supprimer tout ce que Windows vous laissera supprimer dans le répertoire C:\Windows\system32\inetsrv.
- Redémarrez la machine.
- Tout installer dans le groupe "Services Internet (IIS)\Service d'activation des processus Windows".
- Tout installer dans le groupe "Services Internet (IIS)\Outils d'administration Web".
- Tout installer dans le groupe "Services World Wide Web Services".
Have fun avec la session ! _0/
(/!\ attention, la session c'est bien, en abuser ça craint) |
| permalien & reactions (3) |
|
| mardi 14 octobre 2008 |
| 09:27 » Crosspage postback : PreviousPage est systématiquement à null ? - programmation, Asp.net |
Symptôme : dans votre application ASP.NET, vous devez modifier un bouton qui faisait précédemment du postback classsique de façon à ce qu'il fasse du crosspage postback (autrement dit, qu'un clic sur le bouton provoque un postback sur une autre page que la page courante).
Vous donnez donc une valeur à la propriété PostbackUrl du bouton, et vous servez de la propriété Page.PreviousPage pour connaitre le contenu des contrôles de la page d'où vous venez. Seulement voilà, la propriété Page.PreviousPage est désespéremment nulle. Wtf ?! oO
Solution : vous avez probablement oublié d'enlever le handler sur l'évènement Click du bouton qui est présent dans la page d'origine.
Sinon rien à voir avec le crosspage postback, mais il y a quelques astuces ASP.NET intéressantes sur cette page : http://www.kevinjensen.com/2007/04/22/aspnet-20-hot-tips-and-tricks/ |
| permalien & reactions (0) |
|
| mardi 03 juin 2008 |
| 14:38 » ASP.NET : les contrôles en session, c'est non. - programmation, informatique, Asp.net |
Une mésaventure m'est récemment arrivée à cause d'un contrôle mis en session. Au moment de coder l'ajout du contrôle en session, j'avais bien senti une perturbation dans la Force, mais je n'arrivais à mettre le doigt sur ce qui me dérangeait... en même temps il était 4h30 du matin et c'était teeeeeeeellement pratique de procéder comme ça. J'ai donc vite oublié ce malaise, jusqu'à ce que le site se mette à crasher pour un oui pour un non. Le problème, c'est que c'était loin d'être le seul changement apporté au site, et on ne savait donc pas d'où venait le problème. On a donc dû faire appel aux shamans de chez Microsoft pour qu'ils déchiffrent les inscriptions runiques contenus dans le dump mémoire du serveur, ce qui a fini par nous amener à la conclusion suivante : il y a un chacal qui met n'importe quoi en session.
Zut, c'est moi :-/
Syndrome : votre site ASP.NET crashe un peu n'importe quand en levant des OutOfMemoryException
Cause possible : vous avez mis des contrôles en session et/ou en cache
Explication : imaginons qu'à chaque chargement de vos pages, vous mettiez en session une référence à un contrôle afin de pouvoir changer son contenu tranquillou par la suite (par exemple parce que vous voulez le faire en même temps que d'autres trucs dans un appel Ajax, mais que vous n'avez pas accès à toute l'arborescence des contrôles, et donc que vous pouvez toujours vous brosser pour faire un FindControl (parce que vous faites de beaux appels Ajax, et pas un truc de bourrin qui produit un postback complet de votre page)).
Tout seul sur votre serveur de développement, vous ne constaterez probablement pas de problème. En revanche, à plusieurs, ça devient problématique. En effet, lorsque vous mettez votre contrôle dans l'objet Session ou Cache, vous l'empêchez purement et simplement d'être désalloué par le garbage collector. "Aucun problème", vous dites-vous, "le contrôle sera détruit en même temps que la page qui le contient, c'est-à-dire dès la fin du rendu de la page". "Pas du tout" vous répondrais-je, "puisque l'objet Session/Cache contient toujours une référence vers votre contrôle, il sera considéré comme utilisé et ne sera donc pas collecté". Si ce n'était que pour un contrôle, ça ne serait pas grave, d'autant plus que, la référence étant écrasée à chaque chargement de page, il finira bien par être collecté. Seulement voilà, comme le contrôle est toujours "vivant", tous les objets qu'il référence le sont également, et leur mémoire ne peut donc pas être récupérée. Or, dans les contrôles ASP.NET, on trouve entre autres les propriétés Parent, qui donne une référence vers le contrôle parent, et Page, qui donne une référence vers l'objet Page contenant le contrôle. Autrement dit, lorsque vous mettez un contrôle en Session/Cache, vous empêchez le garbage collector de récupérer la mémoire pour toute la page contenant ce contrôle. Et quand je dis "toute la page", ça inclut tout ce que la page elle-même référence : contrôle, HttpContext, HttpRequest, HttpResponse, et caetera.
Bref, ça fait des sessions utilisateurs très volumineuses, et donc à plusieurs utilisateurs sur le même serveur, on atteint assez vite le point où il n'y a plus de mémoire, et patatras.
Je le répète une dernière fois : De contrôle en session/cache tu ne mettras point, parce que ça craint.
Si vous êtes plus sensibles aux haïkus :
Contrôles en session
Toute la page reste en mémoire
Mon serveur se meurt
Coïncidence amusante, quelques jours après l'incident, Tess Hernandez postait un article sur le sujet ^_^
|
| permalien & reactions (0) |
|
| mardi 12 février 2008 |
| 20:51 » Asp.net, Ikoula et authentification Forms - programmation, Asp.net |
Symptome : vous disposez d'un hébergement MSDN chez Ikoula, et vous y avez installé un site en Asp.net qui utilise l'authentification Forms. Après vous être identifiés sur le site (quand ça fonctionne), votre session se termine brutalement après un temps aléatoire (mais compris dans les 5 minutes).
Vos logs vous indiquent :- Des erreurs de validation de viewstate (Validation of viewstate MAC failed...)
- Des CryptographicException (Padding is invalid and cannot be removed...), en général sur WebResource.axd
Solution : renseigner vous-même dans le web.config les clés utilisées pour encrypter/décrypter les données qui transitent entre le client et le serveur. Voici une page qui génère le tag qui va bien (cette page provient d'un article sur la machine key), prêt à être copié/collé dans la balise <system.web> de votre fichier de configuration.
Par contre je ne comprends pas très bien pourquoi ça ne fonctionnait pas. Est-ce que le serveur décidait brusquement de changer de clé de cryptage entre deux aller-retour serveur ? Ca expliquerait pourquoi le viewstate était rejeté et les CryptographicException, mais ça me parait quand même bizarre... |
| permalien & reactions (2) |
| musical cue : Zero 7 - Warm Sound |
|
|
|
