背景
- 最近在吃 webflux 这只螃蟹,发现虽然文档中写的会优雅关闭,但其实并没有等待所有请求返回再 shutdown. 如果有还未完成的请求(如sleep 10s的请求),会直接
Empty reply
(环境: spring boot 2.1.5 with reactor-netty 0.8.8)
2020.02.11 Spring 2.2.4 更新
- 更新到 Spring 2.2.4 发现已经修复了之前的 bug,在
reactorResourceFactory
关闭时 block 关闭了 netty 的资源池。
- 但是已测试,发现问题又出现了,又会出现
Emtpy reply
。并不是期望的先完成业务响应再断开所有链接。
- 因为 netty 了解不多,查了不少资料,发现 netty 的优雅关闭只是保证了没有在 socket buff 内没法完的数据包,并不保证 worker 上没有还在执行的 channel,其 quite time 也只是关闭后再等待一会再真实杀掉主程序。
- 那么该怎么办呢?从网上找到了个不错的思路, 可以在 WebFilter 上增加个当前请求计数器,然后在关闭前先阻塞等待关闭。由于 bean 顺序问题,WebFilter bean 会阻塞住 reactorResourceFactory 关闭
- 如果需要先关闭端口(比如上层是 TCP 的心跳检测,需要不进新流量),那么调用
reactiveWebServerApplicationContext
上下文拿到 WebServer 关闭即可
- 具体代码如下
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.web.reactive.context.ReactiveWebServerApplicationContext;
import org.springframework.stereotype.Component;
import org.springframework.web.server.ServerWebExchange;
import org.springframework.web.server.WebFilter;
import org.springframework.web.server.WebFilterChain;
import reactor.core.publisher.Mono;
import javax.annotation.PreDestroy;
import java.util.concurrent.atomic.AtomicBoolean;
import java.util.concurrent.atomic.AtomicInteger;
@Component
@Slf4j
public class DrainDownFilter implements WebFilter {
private final AtomicInteger inFlight = new AtomicInteger(0);
private final AtomicBoolean inDraining = new AtomicBoolean(false);
@Autowired
ReactiveWebServerApplicationContext reactiveWebServerApplicationContext;
@Override
public Mono<Void> filter(ServerWebExchange serverWebExchange, WebFilterChain webFilterChain) {
return webFilterChain.filter(serverWebExchange).doFirst(inFlight::incrementAndGet)
.doFinally((x) -> inFlight.decrementAndGet());
}
@PreDestroy
void preDestroy() {
log.warn("Start draining. ({} in-flight requests)", this.inFlight);
this.inDraining.set(true);
reactiveWebServerApplicationContext.getWebServer().stop();
for (int i = 0; i < 30; i++) {
int current = this.inFlight.get();
if (current <= 0) {
break;
}
try {
log.warn("Draining... ({} in-flight requests)", current);
Thread.sleep(1000);
}
catch (InterruptedException e) {
}
}
log.warn("Good bye. ({} in-flight requests)", this.inFlight);
}
}
根因&解法(已过期)
- 跳过分析不表,直接说结论
- 虽然 netty 本身有 graceful shutdown,并且在关闭时也的确调用到了,但是 reactor netty 调用的方式如下
@Override
default void dispose() {
disposeLater().subscribe();
}
- 直接调用了 subscribe ,并没有 blocking 到完成,因此如果后续 spring shutdown 了,这个过程会直接中断,就造成了上述问题。
- 那么如何解决呢?
- 由于不太熟悉 webflux 这一套,不知道怎么等待所有 subscribe 完成,所以采用了一个比较 hack 的方法,启动后通过反射拿到内部的 HttpResources 然后注册了一个关闭钩子,直接在调用 blocking 方法,阻塞得释放掉LoopResources,这样就没问题了
@Component
public class GracefulShutdown {
@Autowired
ReactorResourceFactory reactorResourceFactory;
LoopResources loopResources;
@PostConstruct
void init() throws Exception {
Field field = TcpResources.class.getDeclaredField("defaultLoops");
field.setAccessible(true);
loopResources = (LoopResources) field.get(reactorResourceFactory.getLoopResources());
field.setAccessible(false);
Runtime.getRuntime().addShutdownHook(new Thread(() -> {
System.out.println("Graceful: block long to 20s before real shutdown!");
loopResources.disposeLater().block(Duration.ofSeconds(20));
}));
}
}
关联知识
Spring 关闭流程
- 启动时会注册一个关闭钩子
org.springframework.context.support.AbstractApplicationContext#registerShutdownHook
- 真实关闭流程
org.springframework.context.support.AbstractApplicationContext#doClose
- 关闭上下文
- 关闭 lifecycle bean
- 关闭 beanFactory 生成的单例 bean (NettyServer 的关闭就在这)
- 关闭 BeanFactory
- 关闭 DisposableServer
- 移除监听器,设置状态为 inactive
- 测试发现,在关闭 bean 过程中,当
reactorServerResourceFactory
关闭后(org.springframework.http.client.reactive.ReactorResourceFactory#destroy
),端口就已经关闭,但还未响应的请求还可继续响应。
- 因此还有种 hacker 方式是利用类复写在这边改写关闭逻辑,在关闭 reactorServer 后等待一段时间。但过于 hacker ,万不得已不要使用
参考资料
- Netty 优雅退出机制和原理
- Spring Boot 2.1.5 Source Code
- Reactor Netty 0.8.8 Source Code
- Netty 4.1.36 Source Code