Forum Discussion

leonlu_382273's avatar
leonlu_382273
Icon for Nimbostratus rankNimbostratus
Jan 30, 2019

webserivce 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

 

6 Replies

  • it 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?

     

  • Can you check if cookie persistent has enabled? If yes try to remove and access application with multiple browsers..

     

    • leonlu_382273's avatar
      leonlu_382273
      Icon for Nimbostratus rankNimbostratus

      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's avatar
      leonlu_382273
      Icon for Nimbostratus rankNimbostratus

      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_Bezerra's avatar
      Adriano_Bezerra
      Icon for Altostratus rankAltostratus

      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.