0

我的嵌入式码头应用程序（使用 6.1.26 码头）注册了 2 个上下文处理程序。两者都在同一个端口监听。下面是示例。

Server s = new Server();
Connector c = new SelectChannelConnector();
((SelectChannelConnector)connector).setAcceptors(2);
connector.setHost(IP);
connector.setPort(port);
server.addConnector(connector);

ContextHandler context1 = new ContextHandler();
context.setContextPath("/abc");
context.setHandler(handler1);
context.setAllowNullPathInfo(true);

ContextHandler context2 = new ContextHandler();
context2.setContextPath("/xyz");
context2.setHandler(handler2);
context2.setAllowNullPathInfo(true);

ContextHandlerCollection hc = new ContextHandlerCollection();
hc.addHandler(context1);
hc.addHandler(context2);

server.setHandler(hc);
server.start();

我还使用了在服务器级别设置的线程池。当我向一个上下文发送请求并对其施加负载以便使用所有线程时，那时当我向第二个上下文发送请求时，需要花费时间来处理对第二个上下文的请求。

我还尝试通过在 SelectChannelConnector 级别设置线程池并尝试过。还尝试使用相同的主机/端口添加更多连接器，以便每个连接器都有自己的线程池。

我的要求是，当一个上下文处于负载状态时，其他上下文（但端口相同）不应延迟处理。

我可以为每个上下文设置专用线程池吗？有没有其他解决方法。感谢对此的回复。

谢谢萨拉特

4

1 回答 1

0

With Jetty, the ThreadPool is at the connector level you can't have 2 different ThreadPools for handling different contexts. As the connector accepts the request, it pulls a Thread from the ThreadPool, and hands it off to the Server.getHandler() chain. at which point it goes through the hierarchy of handlers until one of your Contexts is used.

This means that the knowledge of the context comes in far too late to split up the ThreadPools.

Have you tried upgrading to Jetty 8 or Jetty 9 and using Async processing instead?

Or have you tried using the QoSFilter in Jetty 7, 8, or 9 to prioritize the handling better?

于 2013-03-27T15:54:15.287 回答