Завершить http.Request асинхронно в Golang

Я хочу поставить все прибывающие http.Request s в очередь и иметь отдельный поток (goroutine?) Обрабатывать эти запросы и возвращать соответствующий статус.Завершить http.Request асинхронно в Golang

Однако основной обработчик http request выполняет запрос, даже если объект http.Request отправлен асинхронно на goroutine.

Есть ли способ управления, когда http.Request завершен и тем самым асинхронно его обрабатывает?

[Update]

Я хочу реализовать модель производитель-потребитель. Основной обработчик запросов создает запросы и помещает их в очередь. Потребительский поток (или потоки) будет читать эти запросы, потреблять тело запросов и возвращать их.

источник

2015-10-13 Shri Javadekar

Я должен признать, что я не понимаю, что ваш вопрос здесь? Пакет net/http _does_ обрабатывает запрос асинхронно уже. И, конечно же: если обработчик завершает запрос, это делается. Если вы не хотите этого, ваш обработчик не должен заканчиваться, но выполняйте свою другую работу, которую вы намереваетесь делать асинхронно. – Volker

Полезно знать, что пакет net/http обрабатывает HTTP-запросы асинхронно. Но я хочу вытолкнуть все HTTP-запросы в очередь от обработчика (продюсера) и попросить другой поток (потребитель) прочитать эти запросы и свои данные и вернуть их (я уточню основной вопрос с некоторыми из них для лучшей видимости). –

Хорошо, я думаю, что это бессмысленно, поскольку это делает запрос обработкой ** синхронного ** процесса, но это можно сделать: обработчик запроса перенаправляет запрос в канал 1 и _waits_ (!!), пока потребитель не обработает запрос ожидая результата на канале 2. Потребитель слушает на канале 1, захватывает запрос, обрабатывает их и возвращается к производителю через канал 2. Полная последовательная обработка. Не делай этого, это абсурд. Go http server _is_ уже является производителем и вашими обработчиками _are_ потребителями, нет необходимости повторять эту работу. – Volker

http-обработчики выполняются в другой версии goroutine для каждого запроса, поэтому, если вы просто пытаетесь освободить основной цикл обслуживания, это не обязательно.

Если вы хотите сериализовать обработку запросов, вы можете использовать sync.Mutex и заблокировать блокировку этого обработчика. Это будет иметь аналогичный эффект, так как запросы будут обрабатываться по одному.

Я не думаю, что sync.Mutex является честным, поэтому он может не соответствовать вашим потребностям.

также, если вы хотите быть сдержанным между запросами, то это, вероятно, не подходит.

Как отметил Хорхе Марей, каналы будут работать.

Хотя, я предлагаю вам посмотреть на golang.org/x/net/context, поскольку это пакет, специально предназначенный для многоступенчатой обработки с тайм-аутами и еще много чего.

мое предположение, вы будете в конечном итоге с каналом, который проходит, что Структуры выглядеть следующим образом:

type Req struct{ 
    ctx context.Context 
    w http.ResponseWriter 
    r *http.Request 
}

источник

2015-10-13 15:39:26

Завершить http.Request асинхронно в Golang

ответ

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