[jira] [Commented] (TS-2184) Fetch from cluster with proxy.config.http.cache.cluster_cache_local enabled

["Zhao Yongming (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TS-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911428#comment-13911428 ] 

Zhao Yongming commented on TS-2184:
-----------------------------------

when Cluster is designed, the origin goal is to have ONLY one single valid content in the cluster, that is a good idea when you have very huge volume contents, and we have continued on this target, make sure even when some of the machines flapping in the cluster , to ensure that at anytime there is only one valid content in the cluster.

but consider of the ICP protocol and others, those may have multiple same content in the ICP cluster, and if you make it complex, it may have multi-version content in the cluster at sometime. so, ICP alike protocols is consider as a not so cool(safe) protocol if you need to enforce of the consistency of the contents you provide to the user agents.

back to this requirement, we can make the cluster act like ICP, first write to the cluster hashing machine, and the second or later read poll that content from the cluster and write to the local, but it will introduce the consistency problem here, you don't know who have that content local in the cluster when it is updated on the origin side, within the freshness. in most case, all write to the cache haveto broadcast to all the machines in the cluster, to enforce that change.

the proxy.config.http.cache.cluster_cache_local enabled is a directive to disable cluster hashing in the cluster mode, our origin target is to use it to put some very hot hostnames(or urls) in the local, to reducing the intro-cluster traffic. proxy.config.http.cache.cluster_cache_local enabled is override-able and we have the same directive in the cache.config too. if it is in active, Cluster may consider as mode=3, the single host mod.

so, if we want to achive ICP alike feature in cluster, mostly we should:
1, write the content on the hashing machine, if it is a miss in the cluster
2, read the cluster if it is missing in the local machine
3, write the local if it is a hit in the cluster
4, broadcast the change to all the machines in the cluster, if it is a overwrite(ie, revalidating etc)
5, purge on the hashing machine and broadcast the purge to all the machines in the cluster
it will be a very big change in the Cluster and http transaction

cc [~zwoop]


> Fetch from cluster with proxy.config.http.cache.cluster_cache_local enabled
> ---------------------------------------------------------------------------
>
>                 Key: TS-2184
>                 URL: https://issues.apache.org/jira/browse/TS-2184
>             Project: Traffic Server
>          Issue Type: Improvement
>          Components: Cache, Clustering
>            Reporter: Scott Harris
>            Assignee: Bin Chen
>             Fix For: 6.0.0
>
>
> With proxy.config.http.cache.cluster_cache_local enabled I would like cluster nodes to store content locally but try to retrieve content from the cluster first (if not cached locally) and if no cluster nodes have content cached then retrieve from origin.
> Example - 2 Cluster nodes in Full cluster mode.
> 1. Node1 and Node2 are both empty.
> 2. Request to Node1 for "http://www.example.com/foo.html".
> 3. Query Cluster for object
> 4. Not cached in cluster so retrieve from orgin, serve to client, object now cached on Node1.
> 5. Request comes to Node2 for "http://www.example.com/foo.html".
> 6. Node2 retrieves cached version from Node1, serves to client, stores locally.
> 7. Subsequent request comes to Node1 or Node2 for "http://www.example.com/foo.html", object is served to client from local cache.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)