Hi,
I understand that when a real server is put out of service with the "no inservice" command, graceful shutdown takes place, where existing sessions continue to flow until they are closed by the end-points of after they time-out. However, sessions are TCP SESSIONS, not USER SESSIONS (browser session). This is causing us a serious problem in a large SAP deployment (global load balancing with 3 distributed data centers): The SAP portal application is actually not using the http 1.1 capability to send multiple GET requests in the same TCP session. Hence, multiple short-live TCP sessions are established through the CSM. Stickyness is provided by cookie insertion.
We installed a custom-developed agent on each portal web server, which put the server out of service via the XML interface, in case of server CPU overload. Everything works fine, but we would like to keep existing USER SESSIONS on the server, in order to not overload the other portal servers with all users that used the overloaded server... But, because of the CSM behaviour, after a few seconds, all users assigned to the overloaded server are moved to another portal server !
As work around, we tried to set the server weight value to 1, but we run into the situation, where all portal servers are overloaded, and therefore receive the same weight.
My question is : is there any way to put a real server in a state, in which the CSM would continue to send NEW TCP SESSIONS to the overloaded server if a valid cookie is provided in the GET request ? I think this would be a better approach as simply working on the TCP level.
Yves Haemmerli
