sailfin
  1. sailfin
  2. SAILFIN-1104

ENHANCEMENT: Time-to-live on all SIP and HTTP sockets

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.0
    • Fix Version/s: milestone 1
    • Component/s: load_balancer
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      1,104
    • Tags:

      Description

      This enhancement is submitted to improve the SIP and HTTP charactristics during
      rolling upgrade.

      A preferred solution for a Ericsson point of view would be to implement a time-
      to-live (TTL) feature on each socket. The TTL would be expressed in time or
      number of messages and once the TTL expires the socket would be closed in a
      controlled way. Once a socket is closed it would be up to the sip-stack or
      external node to re-open them again according to the standard behavior.

      Also making it possible to set the TTL in runtime would enable us to lower it
      during upgrades when a lot of changes in the cluster membership will happen.
      Once the system is back in a stable state the TTL could be set to a very high
      number.

      I believe it's a trade-off between the time it takes to even out the load after
      a failure and the impact on traffic.

        Issue Links

          Activity

          Hide
          pankaj_jairath added a comment -

          This RFE is not related to load balancer. Effectively it is to do with connector
          configuration on the sockets being established by it.

          On a different note I am sure if it really relates to rolling upgrade scenario
          or even the failure and rejoining of instance in the cluster. I suppose this can
          also be achieved by causing some short of connection closure on the cluster when
          the instance joins back into the cluster.

          Under normal execution scenario, atleast for HTTP, keep-alive is best suited to
          achieve lifecycle management of the established connections. This mechanism,
          depending on how it would be triggered (ex: an external cli invocation causing
          the traffic to redistributed due to forced connection closures) would cause to
          override the existing established connections keep-alive by closing them at the
          end of response.

          Show
          pankaj_jairath added a comment - This RFE is not related to load balancer. Effectively it is to do with connector configuration on the sockets being established by it. On a different note I am sure if it really relates to rolling upgrade scenario or even the failure and rejoining of instance in the cluster. I suppose this can also be achieved by causing some short of connection closure on the cluster when the instance joins back into the cluster. Under normal execution scenario, atleast for HTTP, keep-alive is best suited to achieve lifecycle management of the established connections. This mechanism, depending on how it would be triggered (ex: an external cli invocation causing the traffic to redistributed due to forced connection closures) would cause to override the existing established connections keep-alive by closing them at the end of response.
          Hide
          rampsarathy added a comment -

          please see 926

          Show
          rampsarathy added a comment - please see 926
          Hide
          sanandal added a comment -

          Added keyword ocean to track new RFEs

          Show
          sanandal added a comment - Added keyword ocean to track new RFEs
          Hide
          sanandal added a comment -

          Added keyword ocean to track new RFEs

          Show
          sanandal added a comment - Added keyword ocean to track new RFEs
          Hide
          sanandal added a comment -

          Added keyword ocean to track new RFEs

          Show
          sanandal added a comment - Added keyword ocean to track new RFEs
          Hide
          rampsarathy added a comment -

          Closing this because this is no longer a requirement and there is a workaround
          (series of steps) to achieve the required behavior

          Show
          rampsarathy added a comment - Closing this because this is no longer a requirement and there is a workaround (series of steps) to achieve the required behavior

            People

            • Assignee:
              rampsarathy
              Reporter:
              andbur
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: