FAQ
Smarter by Design.Simpler for Business
TR7Enterprise Application Delivery & Security Platform

English

Türkçe

English

Türkçe

Appearance

Advanced

Does saving a configuration change reset the persistence tables? ​

Short answer

It depends on the method and on how the change is applied. Ordinary saves reload the vService without interruption: during this, the SAM table is transferred to the new process and preserved, whereas the Hash table is not transferred and is rebuilt. New Cookie and Current Cookie are not affected at all, since they keep the information in the cookie on the client. Reload in the vService menu, Core Engine or resource (QOS) changes and some general settings, on the other hand, restart the service; in this case, the SAM and Hash tables are emptied.

By Method ​

MethodOrdinary save (reload without interruption)Restart (Reload, Core Engine/QOS change)
SAMPreservedEmptied
HashRebuiltEmptied
New CookieNot affectedNot affected
Current CookieNot affectedNot affected
Self-persistent algorithmsThere is no table; as long as the server list does not change, the mapping stays the sameSame

Settings That Reset the Table in SAM ​

The SAM table is preserved on an ordinary save; however, if one of the following settings changes, the table is also reset during the save: Session ID Format, the Custom Format keys, Cookie Source and, in Current Cookie mode, Cookie Name (Compatibility and limitations). Max Idle and Max Life changes do not reset the table.

In New cookie and Current cookie, the value that identifies the server comes from the Cookie Content field of the Backend Service or from the server's address. If the server's IP or port changes, or if Cookie Name is changed, the existing cookies do not match and the clients are redistributed.

Which Save Restarts the Service? ​

  • The Reload command in the vService's menu (Accessing Dashboard); in a cluster, it runs on both devices together.
  • Core Engine, core, CPU or memory (QOS) changes.
  • A change in the Max. Connections/s, Max. Session Rate/s, Max. Total SSL Connections, Max. SSL Connections/s or Buffer Size(kB) values in the vService Limits profile or in the vService core/thread count; turning Compression on or off on the vService, switching to a Compression profile with a different level, or a change of the level in the profile.
  • A change in the Max. Body Size to Process(kB) value in the WAF profile; since the vService's buffer size is determined by the greater of this value and the Buffer size(kB) value, the service restarts when the buffer size changes.
  • Adding the HTTP 1.0 Header Compatibility action to the vService, removing it, or a change in the Headers to fix list.
  • A failure of the reload without interruption.

The lb service restart command in WEB-CLI performs a reload without interruption by default; if --hardReload true is given, the service is restarted (restarting and status).

Common Misconceptions ​

  • "Every save drops all sessions." SAM is preserved on an ordinary save; the cookie methods are not affected at all.
  • "Reload only rereads the configuration." Reload in the vService menu restarts the service and empties the SAM and Hash tables.
  • "Hash is preserved like SAM too." The Hash table is not transferred during a reload.
  • "In a cluster, the table also exists on the other device." The SAM and Hash tables are separate on each device.

How it is done in the documentation

Related questions