GithubHelp home page GithubHelp logo

Comments (5)

seanmonstar avatar seanmonstar commented on June 23, 2024 1

Reconnect is an interesting case:

  • If the service is established, and svc.poll_ready() is an error, Reconnect swallows it, tosses the svc, and calls new_service().
  • If the Future from new_service itself errors, then Reconnect determines it cannot ever get back up, and returns the connect (NewService::InitError) error.

I don't think the proposed change hurts Reconnect. If anything, it gives it a little more context. It could be adjusted to always reconnect when Status::Closed, but perhaps keep a count of Errs and return after a limit, or something else entirely.

from tower.

seanmonstar avatar seanmonstar commented on June 23, 2024

As a comparison, futures mpsc channel has poll_ready as well, and currently encodes the closed state as a Disconnected SendError.

from tower.

olix0r avatar olix0r commented on June 23, 2024

As a part of this change, I think we should explicitly document that poll_ready errors should be considered fatal. If that can't be the case today (i.e. in reconnect), then we may want to figure out if Status needs to handle the case of benign failures.

from tower.

carllerche avatar carllerche commented on June 23, 2024

Before moving forward with this, I would like to discover a case that is made possible with this change.

A service closing normally can be represented with an Error type today, however there is no standard way to do this. Middleware implementations can always define a trait and require that the inner service's error type implement that trait. In order to justify a change like this, it should provide benefit to the majority of cases.

The original example was a connection pool, where the connection pool needs to know if an inner service failed unexpectedly or closed gracefully. In this example, it is not obvious to me that the connection pool needs to know this. The pool should shield its caller from the details of each individual connection and individual connections may fail without any implication to other connections.

So, I would say this should be a "won't fix" until there is a solid use case driving it.

from tower.

carllerche avatar carllerche commented on June 23, 2024

I'm going to close this as it seems that we are leaning towards "won't fix"

from tower.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.