uCosminexus Application Server, Web Container Functionality Guide
(1) URL that can be controlled by controlling the number of concurrently executed threads
A URL that can be controlled by controlling the number of concurrently executed threads in a URL group indicates the request URI defined in RFC 2616. The URL that can be controlled by controlling the number of concurrently executed threads in a URL group does not include the schema, host, port, and query string of the request URI.
The following is an example of a URL that can be controlled by controlling the number of concurrently executed threads in a URL group:
- The request URI of the received HTTP request:
- http://localhost/webapp/index.html?id=0001
- The part used for controlling the number of concurrently executed threads in a URL group:
- /webapp/index.html
The request URL is mapped in the following order of 1. to 3. Note that the mapping order is same as the order applicable to servlet mapping in the Servlet specifications.
- Exact match
If the request URL and the URL pattern match completely, the matching URL pattern is applied.
- Prefix match
The URL pattern in which the request URL and the prefix are matching and the request URL matches with the longest string, is applied.
- Extension match
If the request URL and the extension match, the matching URL pattern is applied.
Note that if the request URL does not match with the above-mentioned 1. to 3., the number of concurrently executing threads is not controlled in the URL group. In such a request URL, the number of concurrently executing threads is controlled in the Web application.
Examples of URL mapping are explained using the following URL patterns:
Table 2-56 Examples of URL pattern
URL pattern |
URL group corresponding to the URL pattern |
/foo/bar |
Control1 |
/foo/* |
Control2 |
/foo/bar/* |
Control3 |
*.do |
Control4 |
- Mapping example 1: When the request URL is /foo/bar
- Since the request URL completely matches with the URL pattern of Control1, the request URL is distributed to the Control1.
- Mapping example 2: When the request URL is /foo/bb
- Since the request URL does not match completely with any URL pattern, the request URL is distributed to Control2 in which the prefix is matching.
- Mapping example 3: When the request URL is /foo/aa.do
- In this case, the following locations are matching in Control2 and Control4:
- Prefix /foo matches with Control2.
- Extension .do matches with Control4.
- In the mapping order, since prefix match is given priority over extension match, the request URL is distributed to Control2.
- Mapping example 4: When the request URL is /foo/bar/
- In this case, the prefix is matching in Control2 and Control3 respectively.
- Prefix /foo matches with Control2.
- Prefix /foo/bar matches with Control3.
- The request URL is distributed to Control3 in which it matches with the longer string.
- Mapping example 5: When the request URL is /foo/bar/action.do
- In this case, the following locations are matching in Control2, Control3 and Control4:
- Prefix /foo matches with Control2.
- Prefix /foo/bar matches with Control3.
- Extension .do matches with Control4.
- In the mapping order, since prefix match is given priority over extension match, and the URL pattern that matches the longer string is given priority, the request URL is distributed to Control3.
- Mapping example 6: When the request URL is /context/fo
- Since there is no corresponding URL pattern, the mapping of request URL is treated as controlling the concurrently executing threads in the Web application.
- Mapping example 7: When the request URL is /action.do
- Since the extension matches with Control4, the request URL is distributed to Control4.
- Mapping example 8: When the request URL is /boo/action.do
- Since the extension matches with Control4, the request URL is distributed to Control4.
(3) Flow of processing when URL pattern is set in the welcome file
The following figure illustrates the flow of processing when the URL pattern is set in the welcome file. In the example illustrated in the following figure, the context root of Web application is context, and /index.html is set as the web.xml for welcome file. The URL pattern and the definition name for controlling the number of concurrently executing threads in the URL group is as follows:
The flow in the figure is as follows:
- The client sends requests to http: //localhost/context/.
- The J2EE server returns the HTTP status code 302, so that the client can re-access the welcome file set as web.xml. http: //localhost/context/index.html is included in Location header.
- The client that receives the HTTP response sends requests to the value of the Location header (http: //localhost/context/index.html) .
- Since the request of the corresponding Web application is /index.html, the request is controlled by 'controlling the number of concurrently executing threads in the URL group' functionality of Control1. After request processing is complete, index.html is send to the client as response.
All Rights Reserved. Copyright (C) 2013, Hitachi, Ltd.