uCosminexus Application Server, Web Container Functionality Guide

[Contents][Glossary][Index][Back][Next]

4.5.1 Overview of distributing requests by the POST data size

When Web containers are deployed with a cluster configuration, by using the redirector, requests are distributed by the POST data size to the respective Web containers. If you use this functionality, you can forward the very long POST data requests with a long processing time to the specific Web containers. As a result, you can avoid the decrease in the throughput of requests other than the very long POST data requests or can avoid the decrease in response time. When distributing requests in this method, as a prerequisite, you must deploy a Web application on each Web container performing the distribution processing. However, the Web applications deployed on each J2EE server is not required to be the same.

For distributing requests by the POST data size in the cluster configuration, use the worker definition called POST request-distributing worker. The list of worker processes that act as the distribution destinations is defined in the POST request-distributing worker. Based on this definition, requests are distributed to the worker processes by the POST data size. The worker process that acts as the distribution destination of the POST request-distributing worker is called POST request-forwarding worker.

The HTTP requests are distributed to the POST request-forwarding worker.

Note
Even when the session is managed with control based on HTTP Cookie or URL rewriting, if distribution by POST data size is specified, the request distribution destination is determined by the POST data size. Therefore, the session ID of the HttpSession is not inherited even when the request is from the same client.
For example, if HttpSession session ID is generated on J2EE server 1 and the request is forwarded to J2EE server 2, a new HttpSession session ID is generated on J2EE server 2. In this case, if J2EE server 1 is accessed again, the HttpSession session ID generated on J2EE server 2 is being used in the client, so a new HttpSession session ID is generated on J2EE server 1. Therefore, the session of the HttpSession is not inherited.
Note that when the HttpSession session ID is generated on J2EE server 1 and a request is forwarded to J2EE server 2, in that case if HttpSession session ID is not generated on J2EE server 2, the HttpSession session ID of J2EE server 1 will be used as it is, when you re-access the J2EE server 1.