浏览代码

Also call `shutdown` in `Handler.sendStatus`.

Without this, completion queues for server-side sessions _never_ get released, leaking the handler, the operation queue, and the thread the operation queue runs on. Given that GCD by default only spawns ~60 threads for its default operation queue, this can make the whole server process unusable very quickly (after processing roughly 60 events).

I also plan to add tests for this and other cases soon, but before that I'd like to do more cleanup and refactoring to streamline the generated code's interface, to make it more usable and more resilient to such errors.

In addition, we now call `shutdown` without checking for the corresponding operation group's success, to avoid leaking the queue and thread in case of unsuccessful close operations.
Daniel Alm 7 年之前
父节点
当前提交
303f237169
共有 1 个文件被更改,包括 3 次插入6 次删除
  1. 3 6
      Sources/gRPC/Handler.swift

+ 3 - 6
Sources/gRPC/Handler.swift

@@ -119,9 +119,7 @@ public class Handler {
                                       .sendStatusFromServer(statusCode, statusMessage, trailingMetadata),
                                       .sendMessage(messageBuffer)
     ]) { operationGroup in
-      if operationGroup.success {
-        self.shutdown()
-      }
+      self.shutdown()
     }
     try call.perform(operations)
   }
@@ -139,9 +137,7 @@ public class Handler {
                                       .receiveCloseOnServer,
                                       .sendStatusFromServer(statusCode, statusMessage, trailingMetadata)
     ]) { operationGroup in
-      if operationGroup.success {
-        self.shutdown()
-      }
+      self.shutdown()
     }
     try call.perform(operations)
   }
@@ -234,6 +230,7 @@ public class Handler {
       if operationGroup.success {
         completion()
       }
+      self.shutdown()
     }
     try call.perform(operations)
   }