Forum Discussion
leonlu_382273
Nimbostratus
Nimbostratuswebserivce request to F5 pool cannot be Forced offline
Hello, We are testing our application client with F5 as the dispatching. our client is sending the http soap request (a webservice) to the F5 pool, and I saw this request goes to one of the pool member, then I enabled another pool member, and forced offline the last pool member, and tried my client application again, unfortunately I still can see that my request keeps going to that offline pool member. How this could happen? My client webservice request should be a stateless request from application point of view. Thanks & regards, Leon
leonlu_382273it sometimes strange, for example, if I wait a uncertain time, and then repeat my request from same application client, in this case the connection switched to the online pool member. Just try to understand how the offline still possibly receives the request?
Samir_Jha_52506Noctilucent
Can you check if cookie persistent has enabled? If yes try to remove and access application with multiple browsers..
- leonlu_382273
Thanks for the quick answer, could you please advice where I can check this cookie persistent? I am new for the F5 in general.
Thanks & regards, Leon
- leonlu_382273
On the Local Traffic ->Profiles ->Persistence, i saw the cookie option is there, does this mean I should delete that cookie row and try it?
Adriano_BezerraAltostratus
It has the option Action on Service Down, I have used it for a long time and it works very well.
"Action on Service Down" is a Pool setting, and can be found in the GUI (Local Traffic -> Pools). Choose "Advanced" in the Configuration dropdown to reveal the "Action on Service Down" setting.
The possible options are None, Reject, Drop, Reselect
Use "Reject" when you want LTM to explicitly close both sides of the connection when the server goes DOWN. "Reject" is the most commonly used option for the service down setting. This option often results in the quickest recovery of a failed connection since it forces the client side of the connection to close, in many cases triggering an automatic re-connect & re-send of the request in process.
Use "Drop" when sending a RST to the client is not desirable. This method does not immediately reflect the server's state change to the client, and depends on the client to close or otherwise manage the connection.
Use "Reselect" when the client can continue with a new server seamlessly. The request in play at the time of state transition may be lost, so the client will need to be able to recover gracefully to use this option successfully.
Use "None" if you don't want LTM to intervene in managing either side of the connection. Useful if your servers may not be accepting new connections, but should be allowed to continue servicing existing connections when marked DOWN. Also supports custom monitoring designed to support connection bleeding and other non-standard state management schemes.
In environments that I set up I usually use the Reject option, however, each one should analyze what fits best in their environment.