2010-04-24 4 views
4

Проблема в том, что каждый раз страница, которая записывает на сеанс, приведет к тому, что apache будет вечно вешать для определенного сеанса. Как только эта ошибка возникает для одного пользователя, любые дальнейшие изменения любого сеанса любого пользователя приведут к зависанию веб-сайта для этого пользователя.PHP-сессии, которые заставляют Apache неограниченно зависать

Эта проблема была моей единственной целью в течение нескольких дней. У меня есть версия VPS под управлением Windows 2003 и последняя версия XAMPP по умолчанию, использующая стандартный обработчик сеанса PHP. Этот код фактически работает на двух других машинах совершенно нормально, поэтому, хотя мой здравый смысл говорит, что это проблема конфигурации веб-сервера, но на данный момент я готов попробовать что угодно.

При дальнейших исследованиях ошибок в журнале событий Apache, PHP или System отсутствуют ошибки. Ресурсы изобилуют, и нет «шторма дерьма AJAX» или больше, чем пара пишет на сеанс на страницу. Я также внедрил session_write_close(), где это возможно, чтобы попытаться помочь решить проблему.

Я проверил каталог сеанса, который установлен в «C: \ windows \ Temp», и обнаружил, что, как только пользователь входит в эту фазу подвески, этот файл сеанса исключительно заблокирован, и единственный способ разрешить это - остановить Apache и подождите несколько секунд, чтобы файлы разблокировались и удалили их. Мне не интересно, требуется ли удаление.

В самих сеансах содержится всего 4 бита информации. ShoppingCartID, UserID, UserLevel и ссылочный URL и буквенно-цифровые со случайной косой чертой.

сессия секции мой php.ini настроен так, как это:

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 

Я попробовал все, что я могу думать и вся проблема теперь размытость мне. Любые идеи были бы оценены и спасибо за ваше время, читая это :)

+0

Удаление файлов сеанса не требуется. После перезапуска apache вы можете продолжить сеанс. – Kmaid

+0

У меня такая же проблема при установке Apache/Linux, вы когда-нибудь находили решение? – Rowan

+0

Да, я сделал новую установку, все в порядке>.> – Kmaid

ответ

1

Возможно, ваши файлы сеансов заблокированы Windows или некоторые настройки php.ini выполнены неправильно. Пожалуйста, SEE HERE

Почти хочется сказать, что его файлы блокировки.

+0

Настройки сеанса php по умолчанию, за исключением save_path, который является только угрозой безопасности на общих серверах, что это не так. – Kmaid

0

Возможно ли, что ваше приложение внутренне запрашивает страницу с того же сайта снова внутри? Вы можете столкнуться с состоянием гонки, когда страница A запускается, блокирует сеанс, а затем каким-то образом запускает запрос самому себе или страницу B, который также пытается перезапустить сеанс, который теперь заблокирован, и запрос висит.

В противном случае, если подвесить является вызвано файла сеанса быть заблокирован, я предложил бы использовать что-то вроде SysInternal на «Handle», чтобы получить список того, что процессы используют файл сеанса в вопросе.

+0

Невозможно. Есть несколько включений, но нет включений включает и максимальное время выполнения. Я на 99% уверен, что это либо apache, либо PHP, у которого есть блокировка, когда он уходит после того, как вы остановитесь и запустите службу apache. Я все равно проверю это. – Kmaid

+1

У меня тоже была эта проблема. Марк Б. Я не нашел для этого никакой работы, и я использовал centos/unix. я просто изменил свое приложение, чтобы оно не использовало сеансы в этой части – Jason

+0

Так я и решил свою проблему. Возможно, стоит попробовать memcache в качестве менеджера сеансов при отражении – Kmaid

Смежные вопросы