Uploaded image for project: 'Couchbase .NET client library'
  1. Couchbase .NET client library
  2. NCBC-1638

net 2.5.6 : When remote connection drops, sdk throws unhandled exception on Asynchronous KV

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 2.5.6
    • 2.5.6
    • None
    • None
    • 1

    Description

      with current master as of 3/8 (45e84c66d0dc4818d8fdfcf7276835ceaa85614a),
      Against server 4.6.3
      When all connection to nodes drops, sdk throws unhandled exception at MultiplexingConnections.cs line 187. Call stack does not reflect what operation it was but I think it is get or upsert. Regardless, this happens on Asynchronous operation.

      StackTrace:
      at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
      at Couchbase.IO.MultiplexingConnection.ReceiveThreadBody()

      Exception message:
      _message "A blocking operation was interrupted by a call to WSACancelBlockingCall"

      Attachments

        1. log.txt
          332 kB
        2. log2.txt
          8.16 MB
        3. log3.txt
          8.22 MB
        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

          jmorris Jeff Morris added a comment -

          Jae Park [X] -

          Can you run this same test against 2.5.5?

          Thanks,

          Jeff

          jmorris Jeff Morris added a comment - Jae Park [X] - Can you run this same test against 2.5.5? Thanks, Jeff
          jmorris Jeff Morris added a comment -

          A couple points:

          • I don't see any exception or error that has been logged in log.txt
          • "A blocking operation was interrupted by a call to WSACancelBlockingCall" isn't necessarily the bug; this will be thrown if a thread other than the thread listening on the socket closes the socket. I suspect that is what is happening when Dispose is called from another thread and the sockets are cleaned up.
          • The bug is the fact that its not being handled correctly and allowing the consuming process to crash because its unhandled. It should be handled and logged and the app keeps working.
          jmorris Jeff Morris added a comment - A couple points: I don't see any exception or error that has been logged in log.txt "A blocking operation was interrupted by a call to WSACancelBlockingCall" isn't necessarily the bug; this will be thrown if a thread other than the thread listening on the socket closes the socket. I suspect that is what is happening when Dispose is called from another thread and the sockets are cleaned up. The bug is the fact that its not being handled correctly and allowing the consuming process to crash because its unhandled. It should be handled and logged and the app keeps working.

          2.5.5 passed the same test.
          I attached log2.txt . It seems the rest of the log were in buffer and not stored in disk when I killed the process. log2.txt has more logs. Hope that helps.
          I agree that socket closed by other thread is not a bug but this kind of expected exception should not stopping from proceeding rest of procedure, like you said.

          jaekwon.park Jae Park [X] (Inactive) added a comment - 2.5.5 passed the same test. I attached log2.txt . It seems the rest of the log were in buffer and not stored in disk when I killed the process. log2.txt has more logs. Hope that helps. I agree that socket closed by other thread is not a bug but this kind of expected exception should not stopping from proceeding rest of procedure, like you said.

          People

            jmorris Jeff Morris
            jaekwon.park Jae Park [X] (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Gerrit Reviews

                There are no open Gerrit changes

                PagerDuty