Ответ. Сброс () только работает с Firefox

У меня есть модуль, который я использую для таких ситуаций - куда процесс будет работать в течение долгого времени, но иногда застревает по неизвестным и невоспроизводимым причинам. Это - немного hacky, и только работает над Unix (требует сигналов):

import code, traceback, signal

def debug(sig, frame):
    """Interrupt running process, and provide a python prompt for
    interactive debugging."""
    d={'_frame':frame}         # Allow access to frame object.
    d.update(frame.f_globals)  # Unless shadowed by global
    d.update(frame.f_locals)

    i = code.InteractiveConsole(d)
    message  = "Signal received : entering python shell.\nTraceback:\n"
    message += ''.join(traceback.format_stack(frame))
    i.interact(message)

def listen():
    signal.signal(signal.SIGUSR1, debug)  # Register handler

Для использования просто назовите слушать () функция в какой-то момент, когда программа запускает (Вы могли даже придерживаться, это в site.py для имения всех программ Python использует его), и позвольте ему работать. В любой точке отправьте процессу сигнал SIGUSR1, использование уничтожает, или в Python:

    os.kill(pid, signal.SIGUSR1)

Это заставит программу повреждаться к консоли Python в точке, в которой это в настоящее время, показывая Вам отслеживание стека и разрешение Вам управлять переменными. Используйте управление-d (EOF), чтобы продолжить работать (хотя примечание, что Вы, вероятно, прервете любой ввод-вывод и т.д. в точке, о которой Вы предупреждаете, таким образом, это не полностью ненавязчиво.

у меня есть другой сценарий, который делает то же самое, кроме него связывается с рабочим процессом через канал (для обеспечения отладки фоновых процессов и т.д.). Это является немного большим для регистрации здесь, но я добавил его как рецепт .

поваренной книги Python

5
задан Santiago Corredoira 27 November 2009 в 21:28
поделиться

4 ответа

Проблема, которую вы сталкиваются с тем, что отправляемый вами ответ все еще неполный. Несмотря на то, что вы сбрасываете все, что находится в буферах, в браузер, браузер по-прежнему должен ждать окончания ответа или обрабатывать то, что он получил, - отсюда разница между браузерами.

Что еще хуже, вы можете ожидать такого же поведения от некоторых концентраторов промежуточных узлов, межсетевых экранов и т. Д., Расположенных в Интернете между вашим сервером и браузером.

Суть в том, что если вы хотите, чтобы этот браузер что-то делает с вашим потоком данных, вы должны завершить это с помощью Response.End.

2
ответ дан 13 December 2019 в 22:09
поделиться

When you call Response.Flush() before the response is complete (before Content-Length is known), the ASP.NET runtime generates a chunked-encoding partial response. It's up to the browser to decide how to render that. In my testing I've found that browsers do tend to render images ( tags) that are included in a partial response. You might give that a try.

However, be careful about sending too soon; browsers may ignore anything past that point. Browsers do render partial pages all the time, though -- so you can start with the beginning of your page as usual.

In case it's helpful, I walk through an example of this in detail in my book, including a packet trace that shows exactly what happens on the wire: Ultra-Fast ASP.NET.

2
ответ дан 13 December 2019 в 22:09
поделиться

Простой способ решить эту проблему - поместить страницу «Подождите, обрабатывается» перед фактической страницей, которая выполняет работу. Отображается сообщение «подождите», а затем оно немедленно начинает обработку с использованием мета-тега обновления и / или javascript для перенаправления на страницу фактической обработки.

Страница «Пожалуйста, подождите»:

<html>
<head>
  <meta http-equiv="refresh" content="0;url=process.aspx?option1=value&...." />
  <title>Please Wait, Processing</title>
</head>
<body>
  Processing...
</body>
<script type="text/javascript">
  window.location = "process.aspx?option1=value&....";
</script>
</html>

Примечания:

  1. Использование два метода для запуска обработки используются, чтобы гарантировать, что если браузер не может использовать один, он, надеюсь, будет использовать другой метод.
  2. Вам придется заменить URL-адрес обработки и строку запроса в соответствии с требованиями.
  3. Один недостаток этот метод заключается в том, что если пользователь нажимает кнопку браузера назад, они вернутся на страницу «подождите» со страницы «процесс», что означает, что он снова случайно запустит задание. Я оставлю этот вызов для другой темы!
3
ответ дан 13 December 2019 в 22:09
поделиться

Также имейте в виду, что если ваш сервер IIS сжимает вывод с помощью GZIP, он будет игнорировать все Response.Flush звонки.

Это включено по умолчанию в IIS7 и Windows 7.

И, если вы тестируете с помощью Fiddler, обязательно включите режим «Streaming», иначе Fiddler соберет сброшенный HTML-код и удержит его до тех пор, пока подключение завершено.

3
ответ дан 13 December 2019 в 22:09
поделиться
Другие вопросы по тегам:

Похожие вопросы: