1. 01 Oct, 2002 16 commits
  2. 30 Sep, 2002 2 commits
  3. 29 Sep, 2002 12 commits
  4. 28 Sep, 2002 1 commit
  5. 27 Sep, 2002 9 commits
    • Guido van Rossum's avatar
      In wait(), when there's no asyncore main loop, we called · 8cba5055
      Guido van Rossum authored
      asyncore.poll() with a timeout of 10 seconds.  Change this to a
      variable timeout starting at 1 msec and doubling until 1 second.
      
      While debugging Win2k crashes in the check4ExtStorageThread test from
      ZODB/tests/MTStorage.py, Tim noticed that there were frequent 10
      second gaps in the log file where *nothing* happens.  These were caused
      by the following scenario.
      
      Suppose a ZEO client process has two threads using the same connection
      to the ZEO server, and there's no asyncore loop active.  T1 makes a
      synchronous call, and enters the wait() function.  Then T2 makes
      another synchronous call, and enters the wait() function.  At this
      point, both are blocked in the select() call in asyncore.poll(), with
      a timeout of 10 seconds (in the old version).  Now the replies for
      both calls arrive.  Say T1 wakes up.  The handle_read() method in
      smac.py calls self.recv(8096), so it gets both replies in its buffer,
      decodes both, and calls self.message_input() for both, which sticks
      both replies in the self.replies dict.  Now T1 finds its response, its
      wait() call returns with it.  But T2 is still stuck in
      asyncore.poll(): its select() call never woke up, and has to "sit out"
      the whole timeout of 10 seconds.  (Good thing I added timeouts to
      everything!  Or perhaps not, since it masked the problem.)
      
      One other condition must be satisfied before this becomes a disaster:
      T2 must have started a transaction, and all other threads must be
      waiting to start another transaction.  This is what I saw in the log.
      (Hmm, maybe a message should be logged when a thread is waiting to
      start a transaction this way.)
      
      In a real Zope application, this won't happen, because there's a
      centralized asyncore loop in a separate thread (probably the client's
      main thread) and the various threads would be waiting on the condition
      variable; whenever a reply is inserted in the replies dict, all
      threads are notified.  But in the test suite there's no asyncore loop,
      and I don't feel like adding one.  So the exponential backoff seems
      the easiest "solution".
      8cba5055
    • Guido van Rossum's avatar
      Whitespace normalization. · 4a981c73
      Guido van Rossum authored
      4a981c73
    • Guido van Rossum's avatar
      Add a log msg "closing troubled socket <address>" when we receive an · 7597373d
      Guido van Rossum authored
      'x' event for a wrapper and then close it.
      7597373d
    • Guido van Rossum's avatar
      Whle we're at it, show the length of the message output as well. Get · ba7fae18
      Guido van Rossum authored
      rid of the silly "smac" word.
      ba7fae18
    • Guido van Rossum's avatar
      Use the zrpc.log module's log() method so the process identity is · b70bef7f
      Guido van Rossum authored
      logged with the message_output.
      b70bef7f
    • Guido van Rossum's avatar
      If you're going to patch __builtin__, at least do it right, by · 3b4b2508
      Guido van Rossum authored
      importing __builtin__, rather than using __main__.__builtins__.
      3b4b2508
    • Guido van Rossum's avatar
      Add missing import of sys, needed for error logging in except clause · 19ece134
      Guido van Rossum authored
      in load_class().  Found by pychecker.
      19ece134
    • Guido van Rossum's avatar
      e1dbb1bf
    • Guido van Rossum's avatar
      When using textwrap, don't break long words. Occasionally a line will · 02c7e4a8
      Guido van Rossum authored
      be too long, but breaking these at an arbitrary character looks wrong
      (and can occasionally prevent you from finding a search string).
      02c7e4a8