Request collapsing/caching

[Isaac Saldana]

Are you planning on implementing this? If not, I'm happy to take a look at it. Thanks.

[keith]

no plans to implement it in the near future, but would certainly be open for a discussion on how it might be designed.

[Isaac Saldana]

I was able to isolate those calls in another library just fine. It would be cool if this library had everything Hystrix provides. I was initially thinking to create an interface with IsCacheable() and GroupKey() and something like DoWork() for the main callback and Fallback() for the fallback function. DoWork() would return an interface{} and if IsCacheable() is true, it can be stored in an LRU cache. Next time DoWork() is called, it would check the cache. GroupKey() would be to wrap DoWork() with AddRequest() in the following:

type requestPool struct {
    pendingRequests     map[string][]chan interface{}
    pendingRequestsLock sync.Mutex
}

// Groups requests in a queue and only call the callback of the first request.
// The result of that first request will be sent to the waiting requests.
func (r *requestPool) AddRequest(key string, callback func() interface{}) chan interface{} {
    ch := make(chan interface{})
    r.pendingRequestsLock.Lock()
    r.pendingRequests[key] = append(r.pendingRequests[key], ch)
    requestNumber := len(r.pendingRequests[key])
    r.pendingRequestsLock.Unlock()

    // Call callback if it's first request
    if requestNumber == 1 {
        go func() {
            resp := callback()
            r.sendResponse(key, resp)
        }()
    }
    return ch
}

// Send response to all waiting requests in the same group
func (r *requestPool) sendResponse(key string, res interface{}) {
    go func() {
        r.pendingRequestsLock.Lock()
        for _, ch := range r.pendingRequests[key] {
            ch <- res
        }
        delete(r.pendingRequests, key)
        r.pendingRequestsLock.Unlock()
    }()
}

[keith]

avoiding the run/fallback functions returning an empty interface is done on purpose, and is why they make no attempt to handle responses. requiring users to constantly cast results to their expected type is not a good API. an early version of hystrix-go took this approach and was awful to use.

i'm open to adopting these features from java hystrix, but not at the expense of the usability of the library when trying to copy java's use of generics.

[keith]

closing this issue, but still open to ideas around collapsing commands and caching results