Race condition with multiple oplock break requests happens

more often than you might think (reproduced here with 4 clients
and netbench :-).
Raising debug log level for report from 1 to 3.
Jeremy (jallison@whistle.com)
(This used to be commit 23eeab7aa2e9c935e1f48ce3449544c03c1c899f)

diff --git a/source3/smbd/server.c b/source3/smbd/server.c
index 52869505c096b5d8ee1a952af3dd2b63022a009e..b250572a1f43b73d0bf5ea3ee1575ef38dec1d3f 100644 (file)
--- a/source3/smbd/server.c
+++ b/source3/smbd/server.c
@@ -2626,13 +2626,12 @@ allowing break to succeed.\n", dev, inode, fnum));
      have been broken due to another udp request, and yet there are
      still oplock break messages being sent in the udp message
      queue for this file. So return true if we don't have an oplock,
-     as we may have just freed it. But this is an unusual case so
-     we should log a message at low debug priority (1).
+     as we may have just freed it.
    */
 
   if(!fsp->granted_oplock)
   {
-    DEBUG(1,("oplock_break: file %s (fnum = %d, dev = %x, inode = %x) has no oplock. \
+    DEBUG(3,("oplock_break: file %s (fnum = %d, dev = %x, inode = %x) has no oplock. \
 Allowing break to succeed regardless.\n", fsp->name, fnum, dev, inode));
     return True;
   }