Uploaded image for project: 'C# Driver'
  1. C# Driver
  2. CSHARP-775

Tailable cursor blocks forever when connection is lost

    • Type: Icon: Bug Bug
    • Resolution: Won't Fix
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: 1.8.1
    • Component/s: None
    • Environment:
      Mongo 2.4.3

      I'm using the MongoDB C# driver 1.8.1.20 with Mongo 2.4.3. I use the following infinite loop to poll new messages from a capped collection and process them as they come (with a tailable cursor and await data). It works for the most part, but in production, it seems that from time to time the call to enumerator.MoveNext() blocks and never returns. This causes the loop to stall, and my application no longer receives updates. It seems to be happening when the connection is closed unexpectedly (in particular, during a VIP Swap on Windows Azure).

      while (true)
      {
          try
          {
              using (MongoCursorEnumerator<QueueMessage> enumerator = GetCursor())
              {
                  while (!enumerator.IsDead)
                  {
                      while (enumerator.MoveNext()) // This is blocking forever when connection is temporarily lost
                          this.processMessage(enumerator.Current);
                  }
              }
           }
           catch
           {
           }
      }
      

      The GetCursor function does this:

      cursor = (MongoCursorEnumerator<QueueMessage>)collection
          .FindAllAs<QueueMessage>()
          .SetFlags(QueryFlags.AwaitData | QueryFlags.TailableCursor)
          .SetSortOrder(SortBy.Ascending("$natural"))
          .GetEnumerator();
      

      Either the disconnection should be detected and an exception be thrown, or there should be a timeout exception. The call should not block forever.

            Assignee:
            Unassigned Unassigned
            Reporter:
            flavien Flavien
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: