Решение от @mdoar (в разделе комментариев)
«Я вижу, что у ресурса rest/api/latest/serverInfo
есть ключ с именем« развертывание », который имеет значение« Сервер »для Jira Server. Это может помочь» [ 112]
В конце я переключился назад на Apache + mod_python (у меня были другие случайные ошибки с fcgi помимо этого), и все хорошо и стабильно теперь.
Вопрос все еще остается открытым. В случае, если кто-либо имеет эту проблему в будущем и решает его, они могут записать решение здесь для дальнейшего использования.:)
Я устранил подобную проблему при использовании geodjango модели, которая не использовала ORM по умолчанию для одной из его функций. Когда я добавил строку для ручного закрытия соединения, ошибка ушла.
http://code.djangoproject.com/ticket/9437
Я все еще вижу ошибку случайным образом (~50% запросов) при выполнении материала с пользовательским входом в систему/сессиями как бы то ни было.
Запахи как возможная проблема многопоточности. Django не гарантируют ориентированному на многопотоковое исполнение, хотя документы в файле, кажется, указывают, что Django/FCGI может быть выполнен тот путь. Попытайтесь работать с предварительным ветвлением и затем взбейте дерьмо из сервера. Если проблема уходит...
Возможно, PYTHONPATH и переменная окружения PATH отличаются для обеих установок (Apache+mod_python и lighttpd + FastCGI).
В переключателе Вы изменяли версии клиента/сервера PostgreSQL?
Я видел подобные проблемы с php+mysql, и преступник был несовместимостью между клиент-серверными версиями (даже при том, что у них была та же основная версия!)
Рассматривали ли вы возможность перехода на Python 2.5.x (в частности, 2.5.4)? Я не думаю, что Django будет считаться зрелым на Python 2.6, поскольку есть некоторые несовместимые изменения. Однако я сомневаюсь, что это решит вашу проблему.
Кроме того, Django 1.0.2 исправил некоторые гнусные маленькие ошибки, поэтому убедитесь, что вы работаете с этим. Это очень хорошо может решить вашу проблему.
Я думаю, что Django будет считаться зрелым на Python 2.6, поскольку есть некоторые несовместимые изменения. Однако я сомневаюсь, что это решит вашу проблему.Кроме того, Django 1.0.2 исправил некоторые гнусные маленькие ошибки, поэтому убедитесь, что вы работаете с этим. Это очень хорошо может решить вашу проблему.
Я думаю, что Django будет считаться зрелым на Python 2.6, поскольку есть некоторые несовместимые изменения. Однако я сомневаюсь, что это решит вашу проблему.Кроме того, Django 1.0.2 исправил некоторые гнусные маленькие ошибки, поэтому убедитесь, что вы работаете с этим. Это очень хорошо может решить вашу проблему.
Недавно я столкнулся с той же проблемой (lighttpd, fastcgi и postgre). Безуспешно искал решение несколько дней и в крайнем случае перешел на mysql. Проблема исчезла.
Почему не сохранять сеанс в кеше? Установите
SESSION_ENGINE = "django.contrib.sessions.backends.cache"
Также вы можете попробовать использовать postgres с pgbouncer (postgres - prefork server и не люблю много подключений / отключений за раз), но сначала проверьте свой postgresql.log.
Другая версия - у вас много записей в сессионных таблицах, и может помочь django-admin.py cleanup .
Проблема могла быть в основном с импортом. По крайней мере, это то, что случилось со мной. Я написал собственное решение, ничего не найдя в Интернете. Пожалуйста, проверьте мою запись в блоге здесь: Простая утилита Python для проверки всех импортов в вашем проекте
Конечно, это поможет вам довольно быстро найти решение исходной проблемы, а не само решение вашей проблемы.
Изменение с method = prefork на method = threadaded решило проблему для меня.
Возможное решение: http://groups.google.com/group/django-users/browse_thread/thread/2c7421cdb9b99e48
До недавнего времени мне было любопытно проверить это в Django 1.1.1. Будет ли это исключение снова генерироваться ... сюрприз, вот оно снова. Мне потребовалось некоторое время, чтобы отладить это, полезный намек был , что он отображается только при (предварительном) форкинге. Так что для тех, кто получает случайно эти исключения , Я могу сказать ... исправьте свой код :) Хорошо ... серьезно, всегда есть несколько способов сделать это, поэтому позвольте мне сначала объяснить, где находится { {1}} проблема первая. Если вы обращаетесь к базе данных , когда какой-либо из ваших модулей будет импортировать как, например, считывая конфигурацию из базы данных , вы получите эту ошибку. Когда ваше приложение fastcgi-prefork запускается, сначала оно импортирует все модули, и только после этого разветвляется дети. Если вы установили соединение с базой данных во время импорта, все дочерние процессы будут иметь точную копию этого объекта . Это соединение закрывается в конце фазы запроса (сигнал request_finished). Итак, первый дочерний элемент , который будет вызван для обработки вашего запроса, закроет это соединение.Но что произойдет с остальными дочерними процессами? Они будут считать, что у них есть открытое и предположительно рабочее соединение с базой данных, поэтому любая операция с базой данных вызовет исключение . Почему это не отображается в модели потокового выполнения ? Я предполагаю , потому что потоки используют один и тот же объект и знают, когда какой-либо другой поток закрывает соединение. Как это исправить? Лучший способ - исправить ваш код ... но иногда это может быть сложно. Другой вариант, на мой взгляд, довольно чистый, - это написать где-нибудь в своем приложении небольшой фрагмент кода:
from django.db import connection
from django.core import signals
def close_connection(**kwargs):
connection.close()
signals.request_started.connect(close_connection)
Не идеальная мысль, дважды подключиться к БД - это обходной путь в лучшем случае.
Возможное решение: использование пула соединений (pgpool, pgbouncer), чтобы соединения с БД были объединены в пул, стабильны и быстро переданы вашим демонам FCGI.
Проблема в том, что это вызывает другую ошибку: psycopg2 вызывает InterfaceError , потому что пытается отключиться дважды (pgbouncer уже обработал это).
Теперь виноват сигнал Django request_finished , запускающий connection.close () , и громкий сбой, даже если он уже был отключен. Я не думаю, что такое поведение желательно, как будто запрос уже завершен, нас больше не волнует соединение с БД. Патч для исправления этого должен быть простым.
Соответствующая трассировка:
/usr/local/lib/python2.6/dist-packages/Django-1.1.1-py2.6.egg/django/core/handlers/wsgi.py in __call__(self=<django.core.handlers.wsgi.WSGIHandler object at 0x24fb210>, environ={'AUTH_TYPE': 'Basic', 'DOCUMENT_ROOT': '/storage/test', 'GATEWAY_INTERFACE': 'CGI/1.1', 'HTTPS': 'off', 'HTTP_ACCEPT': 'application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5', 'HTTP_ACCEPT_ENCODING': 'gzip, deflate', 'HTTP_AUTHORIZATION': 'Basic dGVzdGU6c3VjZXNzbw==', 'HTTP_CONNECTION': 'keep-alive', 'HTTP_COOKIE': '__utma=175602209.1371964931.1269354495.126938948...none); sessionid=a1990f0d8d32c78a285489586c510e8c', 'HTTP_HOST': 'www.rede-colibri.com', ...}, start_response=<function start_response at 0x24f87d0>)
246 response = self.apply_response_fixes(request, response)
247 finally:
248 signals.request_finished.send(sender=self.__class__)
249
250 try:
global signals = <module 'django.core.signals' from '/usr/local/l.../Django-1.1.1-py2.6.egg/django/core/signals.pyc'>, signals.request_finished = <django.dispatch.dispatcher.Signal object at 0x1975710>, signals.request_finished.send = <bound method Signal.send of <django.dispatch.dispatcher.Signal object at 0x1975710>>, sender undefined, self = <django.core.handlers.wsgi.WSGIHandler object at 0x24fb210>, self.__class__ = <class 'django.core.handlers.wsgi.WSGIHandler'>
/usr/local/lib/python2.6/dist-packages/Django-1.1.1-py2.6.egg/django/dispatch/dispatcher.py in send(self=<django.dispatch.dispatcher.Signal object at 0x1975710>, sender=<class 'django.core.handlers.wsgi.WSGIHandler'>, **named={})
164
165 for receiver in self._live_receivers(_make_id(sender)):
166 response = receiver(signal=self, sender=sender, **named)
167 responses.append((receiver, response))
168 return responses
response undefined, receiver = <function close_connection at 0x197b050>, signal undefined, self = <django.dispatch.dispatcher.Signal object at 0x1975710>, sender = <class 'django.core.handlers.wsgi.WSGIHandler'>, named = {}
/usr/local/lib/python2.6/dist-packages/Django-1.1.1-py2.6.egg/django/db/__init__.py in close_connection(**kwargs={'sender': <class 'django.core.handlers.wsgi.WSGIHandler'>, 'signal': <django.dispatch.dispatcher.Signal object at 0x1975710>})
63 # when a Django request is finished.
64 def close_connection(**kwargs):
65 connection.close()
66 signals.request_finished.connect(close_connection)
67
global connection = <django.db.backends.postgresql_psycopg2.base.DatabaseWrapper object at 0x17b14c8>, connection.close = <bound method DatabaseWrapper.close of <django.d...ycopg2.base.DatabaseWrapper object at 0x17b14c8>>
/usr/local/lib/python2.6/dist-packages/Django-1.1.1-py2.6.egg/django/db/backends/__init__.py in close(self=<django.db.backends.postgresql_psycopg2.base.DatabaseWrapper object at 0x17b14c8>)
74 def close(self):
75 if self.connection is not None:
76 self.connection.close()
77 self.connection = None
78
self = <django.db.backends.postgresql_psycopg2.base.DatabaseWrapper object at 0x17b14c8>, self.connection = <connection object at 0x1f80870; dsn: 'dbname=co...st=127.0.0.1 port=6432 user=postgres', closed: 2>, self.connection.close = <built-in method close of psycopg2._psycopg.connection object at 0x1f80870>
Обработка исключений здесь могла бы добавить большей снисходительности:
/usr/local/lib/python2.6/dist-packages/Django-1.1.1-py2.6.egg/django/ db / __ init__.py
63 # when a Django request is finished.
64 def close_connection(**kwargs):
65 connection.close()
66 signals.request_finished.connect(close_connection)
Или это можно было бы обработать лучше на psycopg2, чтобы не выдавать фатальные ошибки, если все, что мы пытаемся сделать, это отключиться, а это уже есть:
/usr/local/lib/python2.6/dist- packages / Django-1.1.1-py2.6.egg / django / db / backends / __ init __. py
74 def close(self):
75 if self.connection is not None:
76 self.connection.close()
77 self.connection = None
Кроме этого, у меня мало идей.