jetty配置文件详解

https://blog.csdn.net/fjslovejhl/article/details/15501091

前面的文章基本上对整个jetty的设计实现有了大概的分析, 这篇文章从源码的角度上来分析一下jetty的配置文件,因为以前在读nginx的时候,比较遗憾读完源码就完事了,没有在那基础上好好的分析掌握一下nginx的配置和使用...所以现在争取每一次源码读的差不多的时候都好好的来看看使用,争取在了解一个东西的实现的基础上也掌握它的用法...

jetty的启动方式后很多中，可以采用嵌入式的方法，也就是在自己的代码中创建jetty的组件对象，然后启动，还有一种启动方法就是服务器启动了，也就是我们常用的方法：在jetty的根目录中敲命令行：java -jar start.jar  ，当然这也是用的最多的启动方法了。。。。

这种启动方法真正会调用org.mortbay.xml.XmlConfiguration来作为启动类，而这个它默认又会读取/etc/jetty.xml文件，这也是我们比较熟悉的jetty的配置文件。。。那么接下来就来看看这个文件中定义的主要内容（jetty的配置文件感觉很像是用xml定义了一种命令脚本，在载入的时候就自动根据它的说明来创建相应的对象）：

<Configure id="Server" class="org.mortbay.jetty.Server">

上述是整个配置文件的root元素，读到它的时候会创建一个server对象，当然这个server对象的创建采用的是默认构造函数，因而可以理解为它是一个空的server。。。那么接下来就是为其填充各种各样的对象了。。。

接下来继续看配置：

1. <Set name="ThreadPool">

2.  

3. <New class="org.mortbay.thread.QueuedThreadPool">

4. <Set name="minThreads">10</Set>

5. <Set name="maxThreads">200</Set>

6. <Set name="lowThreads">20</Set>

7. <Set name="SpawnOrShrinkAt">2</Set>

8. </New>

9.  

10. <!-- Optional Java 5 bounded threadpool with job queue

11. <New class="org.mortbay.thread.concurrent.ThreadPool">

12. <Set name="corePoolSize">50</Set>

13. <Set name="maximumPoolSize">50</Set>

14. </New>

15. -->

16. </Set>

这段配置是用于为当前的server设置线程池，可以看看这个xml元素的名字叫Set，其实也就是调用server的set方法，后面有一个name属性的值为ThreadPool，那么这里就可以知道这个元素其实是要调用server对象的setThreadPool方法，也就是如下方法：

1. //为当前的server设置运行时候的线程池

2. public void setThreadPool(ThreadPool threadPool) {

3. _container.update(this,_threadPool,threadPool, "threadpool",true);

4. _threadPool = threadPool;

5. }

接着在这个set命令后看到了一个New元素，应该猜也能猜出来这里是创建一个对象了吧，它用于创建一个org.mortbay.thread.QueuedThreadPool的对象，然后下面又接着调用了set方法，为这个threadPool对象设置了许多参数，例如最小线程数量，最大线程数量，SpawnOrShrinkAt参数表示最多有多少task可以暂时放到队列里待会执行。。。

那么上面的一段配置代码要干的事情就已经很清楚了吧，创建线程池对象，然后设置它的一些基本属性，然后调用server的setThreadPool方法将其设置为当前server的线程池。。。

配置文件看到这里，就已经清楚了整个jetty的配置文件的脉络了，用一用类似脚本命令的xml配置来完成了整个server对象的创建。。

那么接下来来看配置文件：

1. <Call name="addConnector">

2. <Arg>

3. <New class="org.mortbay.jetty.nio.SelectChannelConnector">

4. <Set name="host"><SystemProperty name="jetty.host" /></Set>

5. <Set name="port"><SystemProperty name="jetty.port" default="8080"/></Set>

6. <Set name="maxIdleTime">30000</Set>

7. <Set name="Acceptors">2</Set>

8. <Set name="statsOn">false</Set>

9. <Set name="confidentialPort">8443</Set>

10. <Set name="lowResourcesConnections">5000</Set>

11. <Set name="lowResourcesMaxIdleTime">5000</Set>

12. </New>

13. </Arg>

14. </Call>

15.  

16. <!-- Use this connector if NIO is not available.

17. <Call name="addConnector">

18. <Arg>

19. <New class="org.mortbay.jetty.bio.SocketConnector">

20. <Set name="port">8081</Set>

21. <Set name="maxIdleTime">50000</Set>

22. <Set name="lowResourceMaxIdleTime">1500</Set>

23. </New>

24. </Arg>

25. </Call>

26. -->

上述配置文件跟上面的Set不太一样，而是采用的call，不过说白了就是调用addConnector方法，为当前的server对象添加一个connector，从上面也可以看到默认情况下创建的还是SelectChannelConnector，也就是所谓的nioConnector，毕竟它的性能相对于bio的SocketConnector要更好。。。

这里我们来解析一下下面为connector设置的参数吧：

host和port参数就不用说了吧，maxIdleTime是一个连接对大的空闲时间，jetty将会为连接设置超时，如果空闲时间超过了这么多，那么会将这个连接关闭。。。。

Acceptors这个参数可能会比较误导人，比如上面设置为2，看起来像是要创建两个ServerSocketChannel，其实不然，这里其实创建了两个SelectSet，而每一个SelectSet都有一个selector，也就是这里创建了两个selector，并且会在线程池中独占两个线程来专门执行select操作。。。。但是一个connector本身只有一个ServerSocketConnector。。。这里只不过是多建立了selector，毕竟多建立selector可以***护一些连接嘛。。在连接数量比较多的时候，特别是大量短连接的时候，可以适当的创建多一些selector。。。。避免同一个selector会维护太多连接，会对性能造成影响。。。。

好了，接下来继续来读配置文件。。。

1. <Set name="handler">

2. <New id="Handlers" class="org.mortbay.jetty.handler.HandlerCollection">

3. <Set name="handlers">

4. <Array type="org.mortbay.jetty.Handler">

5. <Item>

6. <New id="Contexts" class="org.mortbay.jetty.handler.ContextHandlerCollection"/>

7. </Item>

8. <Item>

9. <New id="DefaultHandler" class="org.mortbay.jetty.handler.DefaultHandler"/>

10. </Item>

11. <Item>

12. <New id="RequestLog" class="org.mortbay.jetty.handler.RequestLogHandler"/>

13. </Item>

14. </Array>

15. </Set>

16. </New>

17. </Set>

这段配置应该也还算是比较容易理解吧，调用了server的setHandler方法为当前的server设置handler属性，折后这里的创建了的handler其实是org.mortbay.jetty.handler.HandlerCollection，接着在创建了3个handler，将其保存在这个handlerCollection当中，分别是

（1）我们最熟悉的ContextHandlerCollection

（2）DefaultHandler，用于处理一些前面没有处理的http请求，多半都是一些错误

（3）log的handler。。。

我们知道当一个http请求收到之后，会调用server来处理这个请求，但其实server对象也是调用内部的handler来处理这个http请求，那么这里来看看HandlerCollection是怎么处理的吧，也就是它的handle方法：

1. //处理http请求，这个方***被覆盖的

2. //这里的处理是比较的简单的，说白了就是遍历所有的handler，依次调用他们的handle方法来处理http请求。。每一个handler都要处理

3. public void handle(String target, HttpServletRequest request, HttpServletResponse response, int dispatch)

4. throws IOException, ServletException {

5. if (_handlers!=null && isStarted())

6. {

7. MultiException mex=null;

8. //遍历当前的所有handler，用他们都来处理一下这个请求

9. for (int i=0;i<_handlers.length;i++) {

10. try{

11. _handlers[i].handle(target,request, response, dispatch);

12. }

13. catch(IOException e)

14. {

15. throw e;

16. }

17. catch(RuntimeException e)

18. {

19. throw e;

20. }

21. catch(Exception e)

22. {

23. if (mex==null)

24. mex=new MultiException();

25. mex.add(e);

26. }

27. }

28. if (mex!=null)

29. {

30. if (mex.size()==1)

31. throw new ServletException(mex.getThrowable(0));

32. else

33. throw new ServletException(mex);

34. }

35.  

36. }

37. }

代码很简单吧，就是遍历当前保存的所有的handle，一次调用他们的handle方法。。。也就是说每一次http请求接收到以后，都会调用上面3个handler的handle方法来依次处理。。。

其实这里的handler配置会对整个jetty服务器的性能产生比较大的影响。。。

如果我们只是部署一个应用在jetty的话，那么我们可以将WebAppContext前面的ContextHandlerCollection去掉，这样就可以少了一层path的匹配。。。

最精简的情况下我们可以这么高配置：

1. <Set name="handler">

2. <New id="Handlers" class="org.mortbay.jetty.webapp.WebAppContext">

3. <Set name="extractWAR">true</Set>

4. <Set name="contextPath">/</Set>

5. <Set name="war">file:/F:/360云盘/jettywork/jetty/webapps/manager.war</Set>

6. <Set name="parentLoaderPriority">true</Set>

7. </New>

8. </Set>

将server的handler属性直接设置为一个WebAppContext对象，同时设置这context的path，以及app的路径什么的。。。这样子性能应该是最好的了。。毕竟省去了很多其余的处理过程。。

好了，到这里整个jetty的配置文件最重要的一些内容就算是差不多了。。。接下来还有一些其他的配置，不过基本上都能够很容易搞懂的。。。

总的来说整个jetty的配置还算是比较简单的，现在感觉到如果真的要用好一个东西，对其的实现由一定的了解是很有帮助的。。。