Come interrompere http.ListenAndServe ()

Sto usando la libreria Mux di Gorilla Web Toolkit insieme al server Go http in bundle.

Il problema è che nella mia applicazione il server HTTP è solo un componente ed è necessario arrestarlo e avviarlo a mia discrezione.

Quando lo chiamo http.ListenAndServe(fmt.Sprintf(":%d", service.Port()), service.router)blocchi e non riesco a interrompere l'esecuzione del server.

Sono consapevole che questo è stato un problema in passato, è ancora così? Esistono nuove soluzioni?

Per quanto riguarda l'arresto grazioso (introdotto in Go 1.8), un esempio un po 'più concreto:

package main

import (
    "context"
    "io"
    "log"
    "net/http"
    "sync"
    "time"
)

func startHttpServer(wg *sync.WaitGroup) *http.Server {
    srv := &http.Server{Addr: ":8080"}

    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        io.WriteString(w, "hello world\n")
    })

    go func() {
        defer wg.Done() // let main know we are done cleaning up

        // always returns error. ErrServerClosed on graceful close
        if err := srv.ListenAndServe(); err != http.ErrServerClosed {
            // unexpected error. port in use?
            log.Fatalf("ListenAndServe(): %v", err)
        }
    }()

    // returning reference so caller can call Shutdown()
    return srv
}

func main() {
    log.Printf("main: starting HTTP server")

    httpServerExitDone := &sync.WaitGroup{}

    httpServerExitDone.Add(1)
    srv := startHttpServer(httpServerExitDone)

    log.Printf("main: serving for 10 seconds")

    time.Sleep(10 * time.Second)

    log.Printf("main: stopping HTTP server")

    // now close the server gracefully ("shutdown")
    // timeout could be given with a proper context
    // (in real world you shouldn't use TODO()).
    if err := srv.Shutdown(context.TODO()); err != nil {
        panic(err) // failure/timeout shutting down the server gracefully
    }

    // wait for goroutine started in startHttpServer() to stop
    httpServerExitDone.Wait()

    log.Printf("main: done. exiting")
}

Come menzionato nella yo.ian.grisposta di. Go 1.8 ha incluso questa funzionalità nella libreria standard.

Esempio minimo per Go 1.8+:

    server := &http.Server{Addr: ":8080", Handler: handler}

    go func() {
        if err := server.ListenAndServe(); err != nil {
            // handle err
        }
    }()

    // Setting up signal capturing
    stop := make(chan os.Signal, 1)
    signal.Notify(stop, os.Interrupt)

    // Waiting for SIGINT (pkill -2)
    <-stop

    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
    defer cancel()
    if err := server.Shutdown(ctx); err != nil {
        // handle err
    }

    // Wait for ListenAndServe goroutine to close.

Risposta originale - Pre Go 1.8:

Basandosi sulla risposta di Uvelichitel .

È possibile creare la propria versione di ListenAndServecui restituisce io.Closere non blocca.

func ListenAndServeWithClose(addr string, handler http.Handler) (io.Closer,error) {

    var (
        listener  net.Listener
        srvCloser io.Closer
        err       error
    )

    srv := &http.Server{Addr: addr, Handler: handler}

    if addr == "" {
        addr = ":http"
    }

    listener, err = net.Listen("tcp", addr)
    if err != nil {
        return nil, err
    }

    go func() {
        err := srv.Serve(tcpKeepAliveListener{listener.(*net.TCPListener)})
        if err != nil {
            log.Println("HTTP Server Error - ", err)
        }
    }()

    srvCloser = listener
    return srvCloser, nil
}

Codice completo disponibile qui .

Il server HTTP si chiuderà con l'errore accept tcp [::]:8080: use of closed network connection

Go 1.8 includerà l'arresto grazioso e forzato, disponibile rispettivamente tramite Server::Shutdown(context.Context)e Server::Close().

go func() {
    httpError := srv.ListenAndServe(address, handler)
    if httpError != nil {
        log.Println("While serving HTTP: ", httpError)
    }
}()

srv.Shutdown(context)

Il commit pertinente può essere trovato qui

Puoi costruire net.Listener

l, err := net.Listen("tcp", fmt.Sprintf(":%d", service.Port()))
if err != nil {
    log.Fatal(err)
}

che puoi Close()

go func(){
    //...
    l.Close()
}()

e http.Serve()su di esso

http.Serve(l, service.router)

Poiché nessuna delle risposte precedenti dice perché non puoi farlo se usi http.ListenAndServe (), sono entrato nel codice sorgente http v1.8 ed ecco cosa dice:

func ListenAndServe(addr string, handler Handler) error {
    server := &Server{Addr: addr, Handler: handler}
    return server.ListenAndServe()
}

Come puoi vedere, la funzione http.ListenAndServe non restituisce la variabile del server. Ciò significa che non puoi accedere al "server" per utilizzare il comando Shutdown. Pertanto, è necessario creare la propria istanza "server" invece di utilizzare questa funzione per implementare l'arresto normale.

Puoi chiudere il server chiudendo il suo contesto.

type ServeReqs func(ctx context.Context, cfg Config, deps ReqHandlersDependencies) error

var ServeReqsImpl = func(ctx context.Context, cfg Config, deps ReqHandlersDependencies) error {
    http.Handle(pingRoute, decorateHttpRes(pingHandlerImpl(deps.pingRouteResponseMessage), addJsonHeader()))

    server := &http.Server{Addr: fmt.Sprintf(":%d", cfg.port), Handler: nil}

    go func() {
        <-ctx.Done()
        fmt.Println("Shutting down the HTTP server...")
        server.Shutdown(ctx)
    }()

    err := server.ListenAndServeTLS(
        cfg.certificatePemFilePath,
        cfg.certificatePemPrivKeyFilePath,
    )

    // Shutting down the server is not something bad ffs Go...
    if err == http.ErrServerClosed {
        return nil
    }

    return err
}

E ogni volta che sei pronto per chiuderlo, chiama:

ctx, closeServer := context.WithCancel(context.Background())
err := ServeReqs(ctx, etc)
closeServer()

È possibile risolvere questo problema context.Contextutilizzando un file net.ListenConfig. Nel mio caso, non ho voluto usare un sync.WaitGroupo http.Server's Shutdown()chiamata, e invece affidamento su una context.Context(che è stato chiuso con un segnale).

import (
  "context"
  "http"
  "net"
  "net/http/pprof"
)

func myListen(ctx context.Context, cancel context.CancelFunc) error {
  lc := net.ListenConfig{}
  ln, err := lc.Listen(ctx, "tcp4", "127.0.0.1:6060")
  if err != nil {
    // wrap the err or log why the listen failed
    return err
  }

  mux := http.NewServeMux()
  mux.Handle("/debug/pprof/", pprof.Index)
  mux.Handle("/debug/pprof/cmdline", pprof.CmdLine)
  mux.Handle("/debug/pprof/profile", pprof.Profile)
  mux.Handle("/debug/pprof/symbol", pprof.Symbol)
  mux.Handle("/debug/pprof/trace", pprof.Trace)

  go func() {
    if err := http.Serve(l, mux); err != nil {
      cancel()
      // log why we shut down the context
      return err
    }
  }()

  // If you want something semi-synchronous, sleep here for a fraction of a second

  return nil
}

Quello che ho fatto per questi casi in cui l'applicazione è solo il server e non esegue altre funzioni è installare un http.HandleFuncper un modello simile /shutdown. Qualcosa di simile a

http.HandleFunc("/shutdown", func(w http.ResponseWriter, r *http.Request) {
    if <credentials check passes> {
        // - Turn on mechanism to reject incoming requests.
        // - Block until "in-flight" requests complete.
        // - Release resources, both internal and external.
        // - Perform all other cleanup procedures thought necessary
        //   for this to be called a "graceful shutdown".
        fmt.Fprint(w, "Goodbye!\n")
        os.Exit(0)
    }
})

Non richiede 1.8. Ma se 1.8 è disponibile, allora quella soluzione può essere incorporata qui invece della os.Exit(0)chiamata, se desiderabile, credo.

Il codice per eseguire tutto il lavoro di pulizia viene lasciato come esercizio per il lettore.

Credito extra se puoi dire dove potrebbe essere posizionato più ragionevolmente il codice di pulizia, perché non consiglierei di farlo qui e come questo colpo di endpoint dovrebbe causare l'invocazione di quel codice.

Più credito extra se puoi dire dove quella os.exit(0)chiamata (o qualunque uscita di processo scegli di usare), fornita qui solo a scopo illustrativo, sarebbe più ragionevolmente collocata.

Ancora più credito extra se puoi spiegare perché questo meccanismo di segnalazione del processo del server HTTP dovrebbe essere considerato al di sopra di tutti gli altri meccanismi ritenuti funzionanti in questo caso.