Browse Source

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 years ago
parent
commit
303f237169
1 changed files with 3 additions and 6 deletions
  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)
   }