One ngx_slice_module bug when use nginx as a reverse proxy server

[zhaiyan0011@…]

• Nginx -1.10.2
• Uname -Linux 2.6.32-642.13.1.el6.x86_64

We use nginx as a reverse proxy server , and enable ngx_http_slice_module.
We have a problem:
When the client receives the first slice body, nginx no longer sends the second slice body, and the connection ( for client) is hanging .
Then we debug the problem, we found that before the second slice body sent to client , the connection’s(for client) write’s status as following:
ready is 1 , delayed is 1
After upstream_module use ngx_event_pipe_read_upstream function to read some body response from upstream, then the buffer is full, but due to the write’s delayed status, the response cannot be sent to the client. Because there is no event to call write_event_handler to reset delayed status and timedout status. The upstream_module step in error cycle.
We suspect that this problem is due to execute the wrong timer event handler.
Please check out the attachment for more details.

[zhaiyan0011@…]

Detail of bug

[Roman Arutyunyan]

This looks like a known issue. When limit_rate/sendfile_max_chunk are used with addition/slice/ssi, output can stop at some point. We're currently working on this.

As a workaround, you can disable limit_rate.

[zhaiyan0011@…]

Replying to arut:

This looks like a known issue. When limit_rate/sendfile_max_chunk are used with addition/slice/ssi, output can stop at some point. We're currently working on this.

As a workaround, you can disable limit_rate.

Thank you for your reply.
Our server requires speed limits. We have tried to fix this problem by modifying the ngx_http_slice_module module code, which now appears to be effective.
But we're looking for an official fix, thank you!

[Maxim Dounin]

See also ticket #776 and ​this thread.

[Maxim Dounin <mdounin@…>]

In 6961:903fb1ddc07f/nginx:

Moved handling of wev->delayed to the connection event handler.

With post_action or subrequests, it is possible that the timer set for
wev->delayed will expire while the active subrequest write event handler
is not ready to handle this. This results in request hangs as observed
with limit_rate / sendfile_max_chunk and post_action (ticket #776) or
subrequests (ticket #1228).

Moving the handling to the connection event handler fixes the hangs observed,
and also slightly simplifies the code.

[Maxim Dounin]

Fix committed.