我有一个vertx服务器的完整的最低限度工作示例,如果通过Postman提出请求,该服务器将抛出ClosedChannelException
。从邮递员的角度来看,请求似乎没有失败-收到了预期的响应。只有vertx服务器会引发此错误。
每个新连接仅发生一次。通过邮递员进行的连续呼叫不会触发此错误,但是完全退出邮递员并再次拨打电话将会触发此错误。如果仅使用SSL,也会发生这种情况。如果删除了启用ssl的行,则不会引发此错误。
如果通过邮递员(浏览器/提取)以外的其他方法发出请求,则不会引发异常。因为我只能用Postman复制,所以我可能不会对此感到困扰,但是我看到同一错误每秒在我的AWS的非本地开发环境中出现多次。我不确定这些请求的来源是什么,因为异常不包含该信息,但我的假设是这些是Elasticbeanstalk健康检查。
样品-
package com.acme.server;
import io.vertx.core.AbstractVerticle;
import io.vertx.core.Future;
import io.vertx.core.Vertx;
import io.vertx.core.http.*;
import io.vertx.core.net.*;
import io.vertx.ext.web.Router;
class Main {
public static void main(String args[]) {
// Configure Vertx
Vertx vertx = Vertx.vertx();
// Configure HttpServer
HttpServerOptions httpServerOptions = new HttpServerOptions();
SelfSignedCertificate selfSignedCertificate = SelfSignedCertificate.create();
// Comment out these lines and try `http` request. No exceptions thrown
httpServerOptions.setKeyCertOptions(selfSignedCertificate.keyCertOptions());
httpServerOptions.setSsl(true);
///////////////////////////////////////////////////////////////////////
httpServerOptions.setPort(4443);
HttpServer httpServer = vertx.createHttpServer(httpServerOptions);
// Configure Router
Router router = Router.router(vertx);
router.route("/*").handler(routingContext -> {
System.out.println("Requested route " + routingContext.normalisedPath());
routingContext.response()
.setStatusCode(204)
.end();
});
httpServer.requestHandler(router);
// Deploy Verticle
vertx.deployVerticle(new MyVerticle());
// Listen for java.nio.channels.ClosedChannelException
httpServer.exceptionHandler((exception) -> {
exception.printStackTrace();
});
// Start server
System.out.println("Listening...");
httpServer.listen();
}
}
class MyVerticle extends AbstractVerticle {
@Override
public void start(Future<Void> startFuture) {
startFuture.complete();
}
}
样本输出-
正在听... java.nio.channels.ClosedChannelException 在io.netty.handler.ssl.SslHandler.channelInactive(...)(未知来源) 要求的路线/ dddd 要求的路线/ dddd java.nio.channels.ClosedChannelException 在io.netty.handler.ssl.SslHandler.channelInactive(...)(未知来源) 请求的路线/ dddd
答案 0 :(得分:0)
我认为这可能是由于任何会话信息邮递员缓存所致。关闭邮递员后,连接是否可能被顶点关闭,重新启动邮递员后,请求中是否包含一些缓存的标头值?这些会话信息将对您的服务器无效。这样服务器开始新的连接并且响应正常。 禁用邮递员的缓存设置,然后可能不会发生。