Web container settings
Configure the web container settings.
From the admin console, click...
Servers > Server Types > WebSphere application servers > server > Web Container Settings > Web container.
Default virtual host
Specifies a virtual host that enables a single host machine to resemble multiple host machines. Resources associated with one virtual host cannot share data with resources associated with another virtual host, even if the virtual hosts share the same physical machine.
Select a virtual host option:
- default_host
- The product provides a default virtual host with some common aliases such as the machine IP address, short host name, and fully qualified host name. The alias comprises the first part of the path for accessing a resource such as a servlet. For example, it is localhost:9080 in the request http://localhost:9080/myServlet.
- admin_host
- This virtual host option is another name for the application server; also known as server1 in the base installation. This process supports the use of the administrative console.
- proxy_host
- The virtual host called proxy_host, includes default port definitions, port 80 and 443, which are typically initialized as part of the proxy server initialization. Use this proxy host as appropriate with routing rules associated with the proxy server.
Enable servlet caching
That if a servlet is started once and it generates output to be cached, a cache entry is created containing not only the output, but also side effects of the invocation. These side effects can include calls to other servlets or JSP files, as well as metadata about the entry, including timeout and entry priority information.
Portlet fragment caching requires that servlet caching is enabled. Therefore, enabling portlet fragment caching automatically enables servlet caching. Disabling servlet caching automatically disables portlet fragment caching.
Disable servlet request and response pooling
To disable the pooling of servlet request and servlet response objects that are pooled by the web container. When we disable pooling of servlet request and servlet response objects, new servlet request and servlet response objects are created for each request.
When we disable pooling of servlet request and servlet response objects, new servlet request and servlet response objects are created for each request, which can negatively affect performance, but provides protection from any unforeseen pooling bugs.
Enable API discovery service
To gather information about applications deployed on the server and make it available as Swagger documents.
The API discovery service enables finding REST APIs within the server. We can get a Swagger document with information about the REST APIs.
Number of timeout threads
Number of threads available to handle asynchronous servlet timeout operations per server.
The default of two might be too low if we have many applications using asynchronous servlets that often have timeouts.
Default timeout
Default asynchronous servlet timeout for the server.
The default of 30 seconds can be lowered if responses are not being received quickly enough and there is a viable fall back in the error case. We can raise the value if too many timeouts are being received and the longer timeout produces responses in an acceptable manner to the client. The units are in millisecond, so multiply the number by 1000 to convert to seconds. To configure at a higher granularity, use the AsyncContext setTimeout method programmatically.
Use thread pool to start Runnable objects
Select this option to use the same thread pool where the request originates. This option does not propagate any context from the original request.
Use a work manager to start Runnable objects
Select this option to use a work manager to start the runnable. This option is the default selection. The work manager option propagates any context configured for the selected work manager. This option also requires selecting the JNDI name of the work manager that we will use.
Considerations when using a work manager:
- The context that is propagated is configurable under Resources > Concurrency > Work managers. We can also create new work managers on the same panel.
- The WebSphere Application Server default Work Manager is used unless we specify otherwise. This might not be desirable as other components might be using the work manager and effectively decreasing the number of threads available at one time.
- To make changes to the work manager settings, IBM recommends that we create a work manager so changes to defaults do not affect other components.
- If we have a work manager configured to throw exceptions when the work queue is full, then an exception of type IllegalStateException is thrown to the caller of start(Runnable) and the caller is responsible for handling the exception.
Related: