1. 15 5月, 2012 1 次提交
  2. 22 3月, 2012 23 次提交
  3. 01 11月, 2011 1 次提交
  4. 26 10月, 2011 3 次提交
  5. 17 9月, 2011 1 次提交
  6. 27 7月, 2011 1 次提交
  7. 20 5月, 2011 5 次提交
  8. 04 5月, 2011 1 次提交
  9. 05 3月, 2011 3 次提交
    • S
      libceph: fix msgr standby handling · e00de341
      Sage Weil 提交于
      The standby logic used to be pretty dependent on the work requeueing
      behavior that changed when we switched to WQ_NON_REENTRANT.  It was also
      very fragile.
      
      Restructure things so that:
       - We clear WRITE_PENDING when we set STANDBY.  This ensures we will
         requeue work when we wake up later.
       - con_work backs off if STANDBY is set.  There is nothing to do if we are
         in standby.
       - clear_standby() helper is called by both con_send() and con_keepalive(),
         the two actions that can wake us up again.  Move the connect_seq++
         logic here.
      Signed-off-by: NSage Weil <sage@newdream.net>
      e00de341
    • S
      libceph: fix msgr keepalive flag · e76661d0
      Sage Weil 提交于
      There was some broken keepalive code using a dead variable.  Shift to using
      the proper bit flag.
      Signed-off-by: NSage Weil <sage@newdream.net>
      e76661d0
    • S
      libceph: fix msgr backoff · 60bf8bf8
      Sage Weil 提交于
      With commit f363e45f we replaced a bunch of hacky workqueue mutual
      exclusion logic with the WQ_NON_REENTRANT flag.  One pieces of fallout is
      that the exponential backoff breaks in certain cases:
      
       * con_work attempts to connect.
       * we get an immediate failure, and the socket state change handler queues
         immediate work.
       * con_work calls con_fault, we decide to back off, but can't queue delayed
         work.
      
      In this case, we add a BACKOFF bit to make con_work reschedule delayed work
      next time it runs (which should be immediately).
      Signed-off-by: NSage Weil <sage@newdream.net>
      60bf8bf8
  10. 04 3月, 2011 1 次提交
    • S
      libceph: retry after authorization failure · 692d20f5
      Sage Weil 提交于
      If we mark the connection CLOSED we will give up trying to reconnect to
      this server instance.  That is appropriate for things like a protocol
      version mismatch that won't change until the server is restarted, at which
      point we'll get a new addr and reconnect.  An authorization failure like
      this is probably due to the server not properly rotating it's secret keys,
      however, and should be treated as transient so that the normal backoff and
      retry behavior kicks in.
      Signed-off-by: NSage Weil <sage@newdream.net>
      692d20f5