Jetty configuration file details

The previous article basically gave a rough analysis on the design and implementation of the entire jetty. This article analyzes the jetty configuration file from the perspective of the source code, because when I was reading nginx, i'm sorry to have finished reading the source code. I didn't analyze and master nginx configuration and usage on that basis... so now I want to take a good look at the use of the source code whenever I try to read the source code. I want to know how to use it on the basis of understanding the implementation of something... after jetty is started, many embedded methods can be used, that is, to create jetty component objects in your own code, and then start. Another method is to start the server, that is, our common method: In the root directory of jetty, knock the command line: java-jar start. jar, of course, this is also the most used startup method .... This method will actually call org. mortbay. xml. xmlConfiguration is used as the startup class, which reads/etc/jetty by default. xml file, which is also a familiar jetty configuration file... Next let's take a look at the main content defined in this file (the jetty configuration file feels like a Command Script is defined in xml, automatically create the corresponding object according to its description when loading): [java] <Configure id = "Server" class = "org. mortbay. jetty. server "> the above is the root element of the entire configuration file. When reading it, a server object will be created. Of course, the creation of this server object uses the default constructor, so it can be understood as an empty server... Then fill in a variety of objects for it... Next, let's continue with the configuration: [java] <Set name = "ThreadPool"> <New class = "org. mortbay. thread. queuedThreadPool "> <Set name =" minThreads "> 10 </Set> <Set name =" maxThreads "> 200 </Set> <Set name =" lowThreads "> 20 </ set> <Set name = "SpawnOrShrinkAt"> 2 </Set> </New> <! -- Optional Java 5 bounded threadpool with job queue <New class = "org. mortbay. thread. concurrent. threadPool "> <Set name =" corePoolSize "> 50 </Set> <Set name =" maximumPoolSize "> 50 </Set> </New> --> </Set> the configuration is used to set a thread pool for the current server, you can see that the xml element is called Set, which is actually the set Method of the server. The value of the name attribute is ThreadPool, here we can know that this element is actually calling the setThreadPool method of the server object, that is, the following method: [java] // set the thread pool public void setThreadPool (ThreadPoo L threadPool) {_ container. update (this, _ threadPool, threadPool, "threadpool", true); _ threadPool = threadPool;} a New element is displayed after the set command, you can guess that this is an object. It is used to create an org. mortbay. thread. the QueuedThreadPool object is called NeXT, And the set method is called. Many parameters are set for this threadPool object, such as the minimum number of threads and the maximum number of threads, the SpawnOrShrinkAt parameter indicates the maximum number of tasks that can be temporarily put into the queue for execution... The above section of configuration code is clear about what to do. Create a thread pool object and set some basic attributes of it, call the setThreadPool method of the server to set it to the thread pool of the current server... The configuration file shows the context of the entire jetty configuration file. The entire server object is created using xml configuration similar to the script command .. Next let's look at the configuration file: [java] <Call name = "addConnector"> <Arg> <New class = "org. mortbay. jetty. nio. selectChannelConnector "> <Set name =" host "> <SystemProperty name =" jetty. host "/> </Set> <Set name =" port "> <SystemProperty name =" jetty. port "default =" 8080 "/> </Set> <Set name =" maxIdleTime "> 30000 </Set> <Set name =" Acceptors "> 2 </Set> <set name = "statsOn"> false </Set> <Set name = "confidentialPort"> 8443 </Set> <Set name = "lowReso UrcesConnections "> 5000 </Set> <Set name =" lowResourcesMaxIdleTime "> 5000 </Set> </New> </Arg> </Call> <! -- Use this connector if NIO is not available. <Call name = "addConnector"> <Arg> <New class = "org. mortbay. jetty. bio. socketConnector "> <Set name =" port "> 8081 </Set> <Set name =" maxIdleTime "> 50000 </Set> <Set name =" lowResourceMaxIdleTime "> 1500 </ set> </New> </Arg> </Call> --> the preceding configuration file is not the same as the preceding Set, the call method is used. To put it bluntly, the addConnector method is called to add a ctor for the current server Object. From the above, we can also see that SelectChannelConnector is created by default, which is also called nioConne. After all, its performance is better than bio's SocketConnector... Here we will resolve the parameters set for ctor in: host and port parameters are not required. maxIdleTime is a connection-to-large idle time, and jetty will set a timeout for the connection, if the idle time exceeds so much, the connection will be closed .... The Acceptors parameter may be misleading. For example, if it is set to 2 above, it seems that two serversocketchannels are to be created. In fact, two selectsets are created, and each SelectSet has a selector, that is to say, two selectors are created here, and two threads are exclusive to the thread pool to specifically execute the select Operation .... However, a connector itself only has one serversocketconne... Here, we only create multiple selector instances. After all, you can maintain more connections when multiple selector instances are created .. When the number of connections is large, especially when a large number of short connections are involved, you can create more selector .... Avoid that the same selector will maintain too many connections and affect the performance .... Now, read the configuration file... [Java] <Set name = "handler"> <New id = "Handlers" class = "org. mortbay. jetty. handler. handlerCollection "> <Set name =" handlers "> <Array type =" org. mortbay. jetty. handler "> <Item> <New id =" Contexts "class =" org. mortbay. jetty. handler. contextHandlerCollection "/> </Item> <New id =" DefaultHandler "class =" org. mortbay. jetty. handler. defaultHandler "/> </Item> <New id =" RequestLog "class =" org. mortbay. jetty. Handler. requestLogHandler "/> </Item> </Array> </Set> </New> </Set> is easy to understand, the setHandler method of the server is called to set the handler attribute for the current server. After the discount, the handler created here is actually org. mortbay. jetty. handler. handlerCollection, then three handler are created and saved in the handlerCollection, which is (1) the ContextHandlerCollection (2) DefaultHandler we are most familiar, it is used to process some http requests that have not been processed before, and most of them are handler of some errors (3) log... We know that when an http request is received, the server will be called to process the request. However, the server object also calls the internal handler to process the http request, let's take a look at how HandlerCollection is handled, that is, its handle method: [java] // process http requests, this method will be overwritten // The processing here is relatively simple. To put it bluntly, it is to traverse all handler and call their handle method in turn to process http requests .. Each handler must process public void handle (String target, HttpServletRequest request, HttpServletResponse response, int dispatch) throws IOException, ServletException {if (_ handlers! = Null & isStarted () {MultiException mex = null; // traverse all current handler and use them to process the request for (int I = 0; I <_ handlers. length; I ++) {try {_ handlers [I]. handle (target, request, response, dispatch);} catch (IOException e) {throw e;} catch (RuntimeException e) {throw e;} catch (Exception e) {if (mex = null) mex = new MultiException (); mex. add (e) ;}} if (mex! = Null) {if (mex. size () = 1) throw new ServletException (mex. getThrowable (0); else throw new ServletException (mex) ;}} the code is very simple. It is to traverse all the handle currently saved and call their handle method at a time... That is to say, after each http request is received, the handle methods of the preceding three handler will be called for processing in sequence... In fact, the handler configuration here will have a big impact on the performance of the entire jetty server... If we only deploy an application in jetty, we can remove the ContextHandlerCollection in front of WebAppContext so that path matching can be omitted... In the simplest case, We can configure this high: [java] <Set name = "handler"> <New id = "Handlers" class = "org. mortbay. jetty. webapp. webAppContext "> <Set name =" extractWAR "> true </Set> <Set name =" contextPath ">/</Set> <Set name =" war "> file: /F:/360 cloud Disk/jettywork/jetty/webapps/manager. war </Set> <Set name = "parentLoaderPriority"> true </Set> </New> </Set> sets the handler attribute of the server directly as a WebAppContext object, set the path of the context and the path of the app... In this way, the performance should be the best .. After all, many other processing procedures are saved .. Now, the most important part of the jetty configuration file is almost the same... There are other configurations, but they are easy to understand... In general, the entire jetty configuration is relatively simple. Now I feel that if I really want to use something, it is very helpful to understand its implementation...