Lemme add the shutdown to the catch.

@gipfelen Try changing 'libjemalloc2' to 'libjemalloc-dev' in the Dockerfile. This night I also saw that my App started crashing again when using libjemalloc2. Have rebuild it with libjemalloc-dev this morning and RAM is looking fine again

@swift-nio-bot add to allowlist

Yeah, you can't await in a defer. In this case, a do...catch is probably easier.

Also, is the application fully idle? If so, this is a known behaviour of jemalloc: jemalloc/jemalloc#1398

Of course, oops. I forgot the early-return/switch/else here. Total fail 😅.

Yes, I noticed this.

I wasn't able able to use the defer shutdown with the async, and because the comments said it was safe to call shutdown twice, I thought the safest thing to do was to leave the top-level shutdown.

I'll move the group lifecycle into the async function, though as it's probably the right thing to do.

How much RAM is present on your system?

This patch isn't quite right as we now shut the loop down twice. Can you move the existing event loop construction out of the top-level scope and into this async function instead?

Continuations must be resumed exactly once: this will fail in the event we hit the error path, as we'll resume twice.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Adds a new extension to EventLoopGroup in _NIOConcurrency to provide an asynchronous shutdownGracefully().

Motivation

Shutting down an event loop was special because it used a completion handler and executed on a DispatchQueue because there would be no event loop to use an EventLoopFuture.

Now we have the new Swift concurrency features, we can provide an async shutdownGracefully.

Fixes #1878.

Modifications

Adds EventLoopGroup.shutdownGracefully() async and some code to use it in NIOAsyncAwaitDemo.

There's no obvious way to ask an ELG if it has been shutdown but I made the following local-only changes to verify that this performs as expected:

diff --git a/Sources/NIO/EventLoop.swift b/Sources/NIO/EventLoop.swift
index d18a33dd..972b3b05 100644
--- a/Sources/NIO/EventLoop.swift
+++ b/Sources/NIO/EventLoop.swift
@@ -840 +840 @@ public final class MultiThreadedEventLoopGroup: EventLoopGroup {
-    private enum RunState {
+    public enum RunState {
@@ -852 +852 @@ public final class MultiThreadedEventLoopGroup: EventLoopGroup {
-    private var runState: RunState = .running
+    public var runState: RunState = .running
diff --git a/Sources/NIOAsyncAwaitDemo/main.swift b/Sources/NIOAsyncAwaitDemo/main.swift
index 97a9c0c3..f8b29ace 100644
--- a/Sources/NIOAsyncAwaitDemo/main.swift
+++ b/Sources/NIOAsyncAwaitDemo/main.swift
@@ -60,0 +61 @@ func main() async {
+        print("elg state: \(group.runState)")  // .running
@@ -61,0 +63,7 @@ func main() async {
+        print("elg state: \(group.runState)")  // .closed(nil)
+
+        /// This causes the following error:
+        /// ERROR: Cannot schedule tasks on an EventLoop that has already shut down. This will be upgraded to a forced crash in future SwiftNIO versions.
+        group.next().execute {
+            print("This will not execute.")
+        }

I changed my https://github.com/gipfelen/vaporLinuxLeak such that it uses jemalloc instead of malloc. But after a single call of http://localhost:8080/hello it uses more than 800MB of RAM, and it doesn't get freed (even after 5min +).

I had a similar issue, memory use increased over time using Linux until the app crashed while the same code had no issues on macOS. I was able to solve this by implementing jemalloc in my container

Deployed my Vapor Docker Container on CloudFoundry with 1GB RAM allocated. Since last week I tested my code under production conditions, decoding an 15MB-ish JSON every hour and writing this data to an internal Fluent SQLite DB. I noticed that now over time more and more RAM was used until the container crashed. @Lukasa mentioned jemalloc, hence I googled a bit and found that some other communities had similar issues and overcame them by using this allocator. Using jemalloc my RAM is looking great, after 24hours at about 80MB used. Previously it would have crashed 3 times by now.

My Dockerfile: [...]

================================

Run image

================================

FROM swift:5.4-focal-slim

Make sure all system packages are up to date.

RUN export DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true &&
apt-get -q update && apt-get -q dist-upgrade -y && apt-get -y install libjemalloc2 && rm -r /var/lib/apt/lists/*

ENV LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so**

[...]

@geeksweep Hello if you are still interested, I removed all dependencies in my version, making it usable anywhere. https://github.com/charlymr/onesignal

@marc-medley vapor new vapor_template_apiweb --template https://github.com/VaporExamplesLab/VaporApiWebTemplate should work

@lmcd In short absolutely not.

First, these APIs are additional and gated behind availability checks. This won't stop you using Vapor on older OSes and Vapor 4 will work just as before.

Second, async/await is the most important change in server-side Swift since it was open sourced. Holding off on adopting would be the death of Vapor as people want to migrate to it and will choose other frameworks. We need to do what's best for the community as a whole and it's not feasible to hold back when the majority of users want and can use async/await

@rleconte the aim is to do this in Vapor 4