How much RAM is present on your system?

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**

[...]

@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

<!-- 🚀 Thank you for contributing! -->

<!-- Describe your changes clearly and use examples if possible. -->

<!-- When this PR is merged, the title and body will be --> <!-- used to generate a release automatically. -->

HTTP route handlers now have experimental support for the new async/await features in Swift 5.5. However, WebSockets miss this functionality.

This means, that non blocking work for websockets still requires the use of EventLoopFutures, that tends to lead to harder to read code.

Please also add a version of the RoutesBuilder .webSocket and WebSocket .onText methods that create/support an async context.

Is it worth holding off on this for now? I and others I know are using Vapor (client and server features) on Apple platforms in which several years of OS support are required.

Vapor adopting async/Swift concurrency features will prevent us from using the latest Vapor releases for another year or two.

See: https://forums.swift.org/t/will-swift-concurrency-deploy-back-to-older-oss/49370/160

As far as I understand, this PR adds async/await support, but doesn't remove the current way of doing things (much like in Apple own APIs, an async variant of APIs is added on top of existing ones). So Vapor would make the async APIs available if your current swift version is adequate, and not bother you if it is not.
But I may very well be completely wrong 😅

The thing I'm not sure to understand is if this will be merged into Vapor 4 in an upcoming minor version, of be merged in an upcoming Vapor 5 ? 🤔

With that being said, even if this comes as a breaking change in Vapor 5 and you need to have the new Swift version supporting concurrency to use it, I think it is fine, and people who want to deploy to older macOS versions can still use Vapor 4, and should not prevent people deploying on macOS 12, Linux (or in docker for that matter) to have these improvements as soon as possible rather than in a few years. Especially as Swift structured concurrency looks to be a pretty big improvement for server side swift.

Is your feature request related to a problem? Please describe. I'm try to set up a website with Events, for which the TimeZone of the Date does not matter. Right now, viewing from different timezones always shows different times. I've set the Website to always set UTC with the right date and then save it.

Describe the solution you'd like Setting the date via #date(date, "YYYY-mm-dd HH:mm", static) or #date(date, "YYYY-mm-dd HH:mm", TimeZone: 0) or similar

Describe alternatives you've considered I've tried to edit the Date on the Server before showing it on the website, but could not get it to work. I have an Event Model which gets passed as the model or even a model array.

Additional context Any ideas to work around that problem?

Thank you

thanks to @0xTim got it working by looking at the default DateFormatter link

@denis-ev Just don't tell Leaf to format the date string, format it yourself with DateFormatter, then pass it to Leaf.

Hey @mkll, Then I have to modify a model which would be a bit more of a hassle.

@0xTim gave the tip about creating a custom DateFormatter.

So I'm trying to set a custom leaf tag. I'm checking out the Example, but I'm not sure how to pass the date to it.

@denis-ev Just don't tell Leaf to format the date string, format it yourself with DateFormatter, then pass it to Leaf.

Is your feature request related to a problem? Please describe. I'm try to set up a website with Events, for which the TimeZone of the Date does not matter. Right now, viewing from different timezones always shows different times.

Describe the solution you'd like Setting the date via #date(date, "YYYY-mm-dd HH:mm", static) or #date(date, "YYYY-mm-dd HH:mm", TimeZone: 0) or similar

Describe alternatives you've considered I've tried to edit the Date on the Server before showing it on the website, but could not get it to work. I have an Event Model which gets passed as the model or even a model array.

Additional context Any ideas to work around that problem?

Thank you

Is it worth holding off on this for now? I and others I know are using Vapor (client and server features) on Apple platforms in which several years of OS support are required.

Vapor adopting async/Swift concurrency features will prevent us from using the latest Vapor releases for another year or two.

See: https://forums.swift.org/t/will-swift-concurrency-deploy-back-to-older-oss/49370/160

I was able to create the issue using the 5.5 development toolchain from 2021-06-02. Be sure you build it in release mode, not debug mode by running: swift build -c release

These changes are now available in 4.47.0

Adds a new PlaintextDecoder to easily decode strings in requests and responses. PlaintextDecoder is the default decoder for Content-Type: plain/text. Resolves #2607

Is your feature request related to a problem? Please describe. As per https://discordapp.com/channels/431917998102675485/435928766812913664/833695763296813107 http apis which return content with Content-Type plain/text hit an Abort.httpDecoder error: Unsupported Media Type when decoding.

e.g.

return req.client.get(address).flatMapThrowing { res in
    try res.content.decode(UInt8.self)
}.map { n in
    /// do stuff
}

Describe the solution you'd like I believe it would be in keeping with the rest of the API surface of vapor if this "just worked" (possibly with a requirement to specify the encoder)

I think that means that I'd want a PlaintextDecoder (there's already a PlaintextEncoder) selected based on Content-Type plain/text

Describe alternatives you've considered In my application I'm instead using res.body!.getString(at: 0, length: res.body!.readableBytes)! which feels strictly inferior (albeit hardly a lot of extra typing)

Additional context None

Original comment:

• Created PlaintextDecoder to easily decode raw strings
• Registered PlaintextDecoder as the default decoder for Content-Type: plain/text This fixes #2607

Done. Also added a test case for empty string as the response's body.

I'm unable to reproduce this with the toolchain shipped in Xcode 13. Which snapshot did you use?

Could you add a test that decodes a string as well? Otherwise LGTM