1. 22 4月, 2015 13 次提交
  2. 21 4月, 2015 16 次提交
  3. 20 4月, 2015 11 次提交
    • don't readd entire directories recursively · 861f30cc
      Jeromy 提交于
    • Remove daemon InitDone guard in interrupt handler · bfd12114
      Instead of just terminating right there and then, we cancel the
      context, and let the daemon exit cleanly. This make take a few
      seconds, as the node builder and its child processes do not
      care too much about the context state while building nodes,
      but this can be improved by injecting checks for ctx.Done()
      before time-consuming steps.
      Tor Arne Vestbø 提交于
    • Handle ipfs command interruption by cancelling the command context · cf6a268c
      Instead of assuming the command is the daemon command and closing
      the node, which resulted in bugs like #1053, we cancel the context
      and let the context children detect the cancellation and gracefully
      clean up after themselves.
      
      The shutdown logging has been moved into the daemon command, where
      it makes more sense, so that commands like ping will not print out
      the same output on cancellation.
      Tor Arne Vestbø 提交于
    • Teach http client to abort channel streaming on context cancellation · cc45e21e
      When the response includes the X-Chunked-Output header, we treat that
      as channel output, and fire up a goroutine to decode the chunks. This
      routine need to look for context cancellation so that it can exit
      cleanly.
      Tor Arne Vestbø 提交于
    • Teach http client to cancel request on context cancellation · 661fb0a4
      The context may be cancelled while a request is in flight. We need to
      handle this and cancel the request. The code is based on the ideas
      from https://blog.golang.org/context
      Tor Arne Vestbø 提交于
    • Sync up request context with root context just before calling command · 3d057642
      The context passed on from main() may change before we hit callCommand,
      so setting it in Parse is a bit optimistic.
      Tor Arne Vestbø 提交于
    • main: wait for interrupt to finish before ending command invocation · 00a6e595
      If a command invocation such as 'daemon' is interrupted, the interrupt
      handler asks the node to close. The closing of the node will result in
      the command invocation finishing, and possibly returning from main()
      before the interrupt handler is done. In particular, the info logging
      that a graceful shutdown was completed may never reach reach stdout.
      
      As the whole point of logging "Gracefully shut down." is to give
      confidence when debugging that the shutdown was clean, this is
      slightly unfortunate.
      
      The interrupt handler needs to be set up in main() instead of Run(),
      so that we can defer the closing of the interrupt handler until just
      before returning from main, not when Run() returns with a streaming
      result reader.
      Tor Arne Vestbø 提交于
    • Merge pull request #1099 from ipfs/fix-randperm · d7c91992
      core: bugfix: bootstrap random permutation
      Juan Batiz-Benet 提交于
    • core: bugfix: bootstrap random permutation · ce791406
      the random permutaton for bootstrap peers was not working as
      intended, returning the first four bootstrap peers always.
      this commit fixes it to be a random subset.
      Juan Batiz-Benet 提交于
    • corehttp: disable HTTP keep-alive when shutting down server · 6fe85496
      Once the server is asked to shut down, we stop accepting new
      connections, but the 'manners' graceful shutdown will wait for
      all existing connections closed to close before finishing.
      
      For keep-alive connections this will never happen unless the
      client detects that the server is shutting down through the
      ipfs API itself, and closes the connection in response.
      
      This is a problem e.g. with the webui's connections visualization,
      which polls the swarm/peers endpoint once a second, and never
      detects that the API server was shut down.
      
      We can mitigate this by telling the server to disable keep-alive,
      which will add a 'Connection: close' header to the next HTTP
      response on the connection. A well behaving client should then
      treat that correspondingly by closing the connection.
      
      Unfortunately this doesn't happen immediately in all cases,
      presumably depending on the keep-alive timeout of the browser
      that set up the connection, but it's at least a step in the
      right direction.
      Tor Arne Vestbø 提交于
    • corehttp: ensure node closing/teardown waits for server termination · c9d30849
      When closing a node, the node itself only takes care of tearing down
      its own children. As corehttp sets up a server based on a node, it
      needs to also ensure that the server is accounted for when determining
      if the node has been fully closed.
      Tor Arne Vestbø 提交于