- run the test case in
crosstalk_test.go. - note that it passes.
- comment out the assignment of
pool.Transportin thegroupcache.HTTPPoolOptions. - note that it fails.
this shows that when groupcache instances with out-of-sync peer lists may propagate requests to each other and wait on each other to fulfill the requests. all requests for an object "stuck" in this way will hang until the original context times out.
instead, the library should behave such that when handling a request on the groupcache handler, no further peers should be consulted to prevent a lockup. in this example, the roundtripper returns an error which groupcache handles gracefully:
- the request comes in and
group.Get()is called (code) Get()attempts to find the object locally. if not found, it'll load it from the group (code)load()attempts to get the object from a peer (code)- the crosstalk transport defined in this project returns a new error in the roundtripper; no actual http request is made to the peer
- the error is none of these so the execution continues and the node just gets the value itself.
a similar fix can be applied to other forks of groupcache, as well as the original.