How can i prevent a http connection to close about gin HOT 3 OPEN

By default Gin won't timeout your connection, you need to add your own middleware if you want that functionality. Have you tried this code? What issue are you facing in regard to this?

This scenario isn't something that is usually implemented. Usually, you use asynchronous message queues like Kafka and RabbitMQ when you don't want a response in a set timeframe. If you want service B to reply within the same http request then you should use something that is synchronous like another http request or gRPC call. Waiting for a response from Kafka whilst keeping the http connection open can open a whole host of issues. What if the request or response is lost in Kafka? The client making the http request will wait indefinitely.

I hope this clears things up and answers your question.

from gin.

Thank @jamesstocktonj1 for the response.

• I think i should explain about my case. I attached the diagram. Service A in this diagram is like the adapter to transform http request to message queue. Traditionally, for each request, service A uses 1 go routine for the handler function to receive http request, produce message to a queue to internal services, consume message in a another queue, match the message's correlationID to the corresponding request then response back to client (everything is in 1 and only 1 go routine. We can seperate the produce/consume to different goroutines but the main point is http request and response currently are in the same goroutine). Now is there anyway to receive http request in 1 go routines, produce message to a queue then the go routine terminates. While we open another go routine to consume message from queue then perform somematching context/collerationID and response back to client? To sum up, for each request i want to spawn 2 goroutines: 1 for reading the request's body -> producing message, another one for consuming message -> response back to the client.

• Right now, because of the low cost of context switching and magic go's cocurrent mechanic, the traditional approach may work fine but to me it is not optimized since we have to wait for the corresponding message. Maybe my thought is different from GO's world. Please Let me know your opinion.

from gin.

A context switch will always take less time than making a network call to add to the message queue.

Go's goroutines have even less context to switch than a standard thread due to their lightweight nature. Also as for having to wait for a message. Go's scheduler knows when goroutines are blocked and won't schedule them unless they are unblocked. Therefore when a goroutine is blocked waiting for a http response it will not be blocking another goroutine from being able to run on the cpu.

from gin.