客户端A往服务端发送了1、2、3三个消息，服务端先处理1、处理完之后才会处理2，然后是3。现象：客户端日志记录发送了心跳消息，服务端没收到心跳，超时后服务端关闭sessionA，客户端新建了会话sessionB，过了会又收到了之前sessionA的消息，由于sessionA已经关闭，所以isOpen 方法返回 false。当然现有消息交互方式也是有问题的，客户端记录发送成功，并不表明真的成功了，所

应用本身属于中转层，一方面需要对接python提供的流式接口，然后对前端提供流式接口。最后继承了SseEmitter，重写extendResponse方法生效了，nginx还是认这个头的。开开心心上线了，产品反馈流式接口没生效，还是阻塞然后一下全返回。直接访问应用对应的代理，接口是正常的。openresty版本是1.7，听说1.8 9都没问题，不过这不在范围内，就没多问了。看了chatgpt提供的

想起了之前用httpclient调微信接口时也报过类似的错误，原因是用http线程池，服务端关闭了连接，而连接池不知道，发请求时触发，后续httpclient有升级进行相关检查。我给运维的建议是1、设置upstream的keepalive_timeout小于tomcat的connectTimeOut值，2、把max_fails设置为3。运维只同意修改max_fails=3。一段时间后又查看了ngi

随着docker等容器技术的成熟，使得dev-ops的开发理念得到落实。公司内部提供的容器都是封装好的，于是决定尝试自己在docker上部署第一个应用来练习练习，还是有不少坑的。前提是docker已经在本地安装了，具体安装步骤可以上官网查看。  1、拉取最新的tomcat镜像到本地 sudo docker pull tomcat  2、基于Dockerfile创建镜像文件dockerfile