У меня есть настройки Apache на Windows (да, не очень хорошая идея, но не моя вина).Я открываю всплывающее окно с примерно 32 изображениями, и все, кроме 3 из этих ссылок изображения работают.Изображения поступают из файла TIF и поэтому должны быть преобразованы, поэтому он запускается через мое приложение Django, чтобы сделать все это, и эта часть работает.3 URL-адреса, которые терпят неудачу при повторной работе.
В журнале apache я получаю 29 200 с, а затем 3 500 с, но фактические изображения, которые не удалось загрузить, случайным образом разбросаны среди 29 хороших изображений.Когда я смотрю журнал с помощью tail -f, 500-е появляются через много секунд после 200-х, но с меткой времени ДО них, например так:
192.168.20.45 - - [08/Mar/2012:01:24:28 -0600] "GET /viewer/... 200 44277
192.168.20.45 - - [08/Mar/2012:01:24:28 -0600] "GET /viewer/... 200 52283
192.168.20.45 - - [08/Mar/2012:01:24:28 -0600] "GET /viewer/... 200 44991
192.168.20.45 - - [08/Mar/2012:01:24:29 -0600] "GET /viewer/... 200 33077
192.168.20.45 - - [08/Mar/2012:01:24:22 -0600] "GET /viewer/... 500 16
192.168.20.45 - - [08/Mar/2012:01:24:22 -0600] "GET /viewer/... 500 16
192.168.20.45 - - [08/Mar/2012:01:24:22 -0600] "GET /viewer/... 500 16
DEBUG = False, и администраторы настроены, поэтому я должен получитьэлектронная почта для каждых 500, что происходит в Джанго, я проверил электронную почту, и она работает как ожидалось.В коде, через который я иду, есть операторы журналирования для условий ошибки, и ни один из них не запускает.
Это почти как Apache или Mod_wsgi, знает, что эти соединения входят, но никогда не передает их в код Django, и они просто заканчивают работу.до смерти от того, что кажется тайм-аутом.Chrome DevTools в итоге показывает мне:
**Response Headers**
Connection:close
Content-Type:text/html; charset=utf-8
Date:Thu, 08 Mar 2012 07:24:22 GMT
Server:Apache/2.2.21 (Win32) mod_wsgi/3.3 Python/2.7.2
Set-Cookie:sessionid=d4616w0f850u1eb33q7a6fzf37f840b5; Path=/
Transfer-Encoding:chunked
Vary:Cookie
Я нахожусь в Windows, и Apache говорит об этом при запуске:
[Thu Mar 08 01:38:09 2012] [warn] mod_wsgi: Compiled for Python/2.7.
[Thu Mar 08 01:38:09 2012] [warn] mod_wsgi: Runtime using Python/2.7.2.
[Thu Mar 08 01:38:09 2012] [notice] Apache/2.2.21 (Win32) mod_wsgi/3.3 Python/2.7.2 configured -- resuming normal operations
[Thu Mar 08 01:38:09 2012] [notice] Server built: Sep 9 2011 10:26:10
[Thu Mar 08 01:38:09 2012] [notice] Parent: Created child process 3260
[Thu Mar 08 01:38:09 2012] [warn] mod_wsgi: Compiled for Python/2.7.
[Thu Mar 08 01:38:09 2012] [warn] mod_wsgi: Runtime using Python/2.7.2.
[Thu Mar 08 01:38:09 2012] [notice] Child 3260: Child process is running
[Thu Mar 08 01:38:09 2012] [notice] Child 3260: Acquired the start mutex.
[Thu Mar 08 01:38:09 2012] [notice] Child 3260: Starting 64 worker threads.
[Thu Mar 08 01:38:09 2012] [notice] Child 3260: Starting thread to listen on port 80.
Есть менее 64 запросов, поэтому должны быть оставлены потокичтобы справиться с ними.
Есть идеи о ЧТО происходит?или КАК это выяснить?
РЕДАКТИРОВАТЬ ---- Нет трассировки, вот в чем проблема.Нет никаких указаний на то, что Python когда-либо видел этот запрос.
Да, вы не должны использовать python для обслуживания статических файлов, но вы не можете поместить один TIFF изображения из TIFF с несколькими изображениями в свой файл.Вы должны извлечь его из файла с несколькими изображениями, поместить его в формат, который может отображать браузер, и нет необходимости конвертировать более 100 миллионов изображений TIFF в изображения PNG или JPEG.И это не изображения, которые могут быть просмотрены широкой публикой, но доступны только их «владельцам»
Загружается это на второй машине, и проблема не возникает .....