Uploaded image for project: 'Traffic Server'
  1. Traffic Server
  2. TS-1919

Eliminate CacheLookupHttpConfig

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Reopened
    • Major
    • Resolution: Unresolved
    • None
    • 7.1.0
    • Core
    • None

    Description

      We have a notion of creating (and transmitting) a very tiny subset of HttpConfigParams, in a struct named CacheLookupHttpConfig. As it turns out, this is generally not used, and as far as I can tell, cluster config provides the same / similar functionality (assuring that all nodes in the cluster uses the same config). One complication with this CacheLookupHttpConfig struct is that it sort of violates modularity, in that the I/O core, clustering and HTTPSM share this partial HTTP config in a non-opaque way.

      I have a patch that eliminates this (I'll post it later), but there are two thoughts / questions I'd like to discuss.

      1) Do we feel it adequate to use the cluster config mechanism of distributing / sharing configurations across the cluster? Or do we really think that it's necessary to transfer the configs as part of every Cluster response message?

      2) If we agree to eliminate the CacheLookupHttpConfig in favor of just using HttpConfigParam's (which are synchronized between cluster nodes), how important is it to preserve compatibility in the Cluster protocol? Right now, my patch does not do this (I'd break clustering between e.g. ATS v3.2 and ATS v3.4).

      For 2), we have a few options, the cleanest probably involves knowing the version of the Cluster message (does that exist today?). Before I go down that route, I'd like to ask the people using clustering if they feel it important to retain compatibility such that you can run a cluster with a mix of v3.2 and v3.4 nodes.

      Attachments

        1. TS-1919.diff
          36 kB
          Leif Hedstrom

        Issue Links

          Activity

            People

              zwoop Leif Hedstrom
              zwoop Leif Hedstrom
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated: