Skip to content
This repository has been archived by the owner on Nov 23, 2019. It is now read-only.

Nop client for engine-api #117

Closed
nishanttotla opened this issue Feb 29, 2016 · 6 comments
Closed

Nop client for engine-api #117

nishanttotla opened this issue Feb 29, 2016 · 6 comments

Comments

@nishanttotla
Copy link
Contributor

Docker Swarm is planning to switch to using the engine-api, and move away from samalba/dockerclient.

One of the important provisions in dockerclient is the nopclient functionality (https://github.com/samalba/dockerclient/tree/master/nopclient), which Swarm needs for efficiency reasons.

engine-api currently does not provide this, but it is simple to build. Is this something that would be acceptable if built into engine-api?

@nishanttotla
Copy link
Contributor Author

cc @dongluochen @calavera

@duglin
Copy link
Contributor

duglin commented Feb 29, 2016

@nishanttotla can you elaborate on how this nopclient is used?

@nishanttotla
Copy link
Contributor Author

@duglin it's used here: https://github.com/docker/swarm/blob/master/cluster/engine.go

The primary purpose is to void every action if an Engine goes down in the cluster. It avoids heavy locking around engine/list structs and pending operations. Without this, Swarm performance can degrade.

@calavera
Copy link
Contributor

I'm pretty sure we don't need that. You can probably achieve the same behavior with a custom Transport that always returns a client.

Steps:

1- Implement the RoundTripper interface:

type NopTrip struct {}
func (NopTrip) RoundTrip(*Request) (*Response, error) {
  return nil, errors.New("nop")
}

2- Create a new HTTPClient using that transport:

client := http.Client{
  Transport: NotTrip{},
}

3- Create an API client with this new client:

api, _ := client.NewClient("...", "", client, ...)

🎉

If this doesn't work, we should consider change the code enough to make it work. This approach is way more scalable than the nopclient because we don't have to add new methods to it every time something is added to the client.

@calavera
Copy link
Contributor

As a second note, Swarm should consider using the Circuit Breaker pattern rather than this hack:

http://martinfowler.com/bliki/CircuitBreaker.html

An implementation in Go: https://github.com/rubyist/circuitbreaker

@nishanttotla
Copy link
Contributor Author

@calavera thanks, that sounds like a great suggestion! I'll close this issue for now, and I think we can consider moving away from the nopclient after the 1.2 release next month.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants