1. 08 Apr, 2010 2 commits
    • Iustin Pop's avatar
      ConfdClient: add synchronous wait for replies mode · bfbbc223
      Iustin Pop authored
      
      
      Currently, there is no way for a user of the confd client library to
      know how many replies there should be, whether all have been received,
      etc. This is bad since we can't reliably detect the consistency of the
      results.
      
      This patch attempts to fix this by adding a synchronous WaitForReply
      function that will wait until either a timeout expires, or until a
      minimum number of replies have been received (interested users should
      add similar functionality for the async case). The callback
      functionality will still do call-backs into the user-provided code
      during the wait, but after this function has returned, we know that we
      received all possible replies.
      
      Note: To account for the interval between initial send of the request,
      and calling of this function, we modify the expiration time of the
      request.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
      bfbbc223
    • Iustin Pop's avatar
      ConfdClient: unify some internal variables · 71e114da
      Iustin Pop authored
      
      
      Currently the requests are tracked in _request and in _expire_requests.
      This is conventient, but it restricts the ability to extend the request
      tracking, e.g. via packet stats and/or extension of expiration time.
      
      This patch introduces a new simple class _Request that holds all
      properties of pending requests; it then uses instances of this class as
      values in _request instead of tuples, and removes the _expire_requests.
      
      The only drawback is the change in behaviour of _ExpireRequests:
      previously, it used to scan the list only up to the first non-expired
      request, after which it aborted. Now it will scan the entire dict, which
      (depending on workload) could change the time behaviour. I don't think
      this is a problem, as:
      - deleting from the head of a list is very expensive (list.pop(0);
        list.append() is an order of magnitude more expensive than deleting
        an element from a dictionary and re-adding it)
      - we should have more than tens or hundreds of pending requests; in case
        this assumption changes, we could introduce a no-more-often-than-X
        expiration policy, etc.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
      71e114da
  2. 07 Apr, 2010 5 commits
  3. 06 Apr, 2010 3 commits
  4. 31 Mar, 2010 3 commits
  5. 30 Mar, 2010 1 commit
  6. 26 Mar, 2010 1 commit
  7. 25 Mar, 2010 1 commit
  8. 23 Mar, 2010 14 commits
  9. 22 Mar, 2010 6 commits
  10. 18 Mar, 2010 4 commits