2010-04-24 5 views
4

Le problème est que, de temps en temps, une page qui écrit dans une session provoque le blocage indéfini d'apache pour une session particulière. Une fois que cette erreur se produit pour un utilisateur, toute modification supplémentaire à une session d'un utilisateur entraînera le blocage du site pour cet utilisateur.Sessions PHP provoquant le blocage indéfini d'Apache

Ce problème a été mon seul objectif pendant des jours. J'ai un développement VPS fonctionnant sous Windows 2003 et la dernière version par défaut de XAMPP utilisant le gestionnaire de session PHP standard. Le code en question fonctionne parfaitement normalement sur deux autres machines, même si mon bon sens dit qu'il s'agit d'un problème de configuration de serveur web mais à ce stade, je suis prêt à tout essayer.

Lors d'une analyse plus approfondie, il n'existe aucune erreur dans le journal des événements Apache, PHP ou System. Les ressources sont abondantes et il n'y a pas de "tempête de merde AJAX" ou plus qu'un couple écrit à une session par page. J'ai également implémenté session_write_close() dans la mesure du possible pour essayer d'aider à élever le problème. J'ai vérifié le répertoire de la session qui est défini sur "C: \ windows \ Temp" et trouvé qu'une fois qu'un utilisateur entre dans cette phase de suspension que le fichier de session correspondant est exclusivement verrouillé et la seule façon de résoudre ce problème est d'arrêter Apache et attendez quelques instants que les fichiers soient déverrouillés et supprimez-les. Je ne me demande pas si la suppression est nécessaire.

Les sessions elles-mêmes contiennent seulement 4 bits d'information. ShoppingCartID, UserID, UserLevel et Refering URL et sont alphanumériques avec une barre oblique.

section de la session Mon php.ini est configuré comme ceci:

session.save_handler = files 
session.save_path = "C:\WINDOWS\Temp" 
session.use_cookies = 1 
session.name = PHPSESSID 
session.auto_start = 0 
session.cookie_lifetime = 0 
session.cookie_path =/
session.cookie_domain = 
session.cookie_httponly = 
session.serialize_handler = php 
session.gc_probability = 1 
session.gc_divisor = 100 
session.gc_maxlifetime = 1440 
session.bug_compat_42 = 1 
session.bug_compat_warn = 1 
session.referer_check = 
session.entropy_length = 0 
session.entropy_file = 
session.cache_limiter = nocache 
session.cache_expire = 180 
session.use_trans_sid = 0 
session.hash_function = 0 
session.hash_bits_per_character = 4 

J'ai tout essayé je pense et tout le problème est maintenant un flou pour moi. Toutes les idées seraient appréciées et merci pour votre temps à lire ceci :)

+0

La suppression des fichiers de session n'est pas requise. Une fois Apache redémarré, vous pouvez continuer la session. – Kmaid

+0

J'ai exactement le même problème sur une installation Apache/Linux, avez-vous déjà trouvé une solution? – Rowan

+0

Oui, j'ai fait une nouvelle installation tout va bien>.> – Kmaid

Répondre

1

Il pourrait être vos fichiers de session se verrouillé par Windows ou certains paramètres de php.ini pas fait correctement. S'il vous plaît SEE HERE

Presque envie de dire ses fichiers de verrouillage.

+0

Les paramètres de la session php sont les paramètres par défaut à l'exception de save_path, ce qui n'est qu'un risque de sécurité sur les serveurs partagés, ce qui n'est pas le cas. – Kmaid

0

Est-il possible que votre application demande à nouveau une page du même site en interne? Vous pourriez rencontrer une condition de concurrence où la page A se déclenche, verrouille la session, puis déclenche une requête vers elle-même, ou la page B, qui tente également de redémarrer la session, qui est maintenant verrouillée, et la requête bloque.

Sinon, si le blocage est provoquée par le fichier de session étant verrouillé, je suggère d'utiliser quelque chose comme SysInternal de « Handle » pour obtenir une liste des processus qui utilisent le fichier de session en question.

+0

Ce n'est pas possible. Il y a quelques inclus mais aucune inclut d'inclus et un temps d'exécution maximum est placé. Je suis sûr à 99% que ce soit apache ou PHP qui a le verrou car il disparaît après que vous arrêtez et démarrez le service apache. Je vais vérifier cela de toute façon. – Kmaid

+1

J'ai aussi eu ce problème Marc B. Je n'ai trouvé aucun travail pour ça et j'utilisais un centos/unix. Je viens de changer mon application pour qu'elle n'utilise pas de sessions dans cette partie. – Jason

+0

Voici comment j'ai résolu mon problème. Peut-être vaut-il la peine d'essayer memcache en tant que gestionnaire de sessions après réflexion – Kmaid