I had to downgrade to tag 0.2 for the app. to work on Cloud Foundry.

The Hello World app (pinned to swift 2.2 but don't think that matters) is at

https://github.com/ragsns/Curassow-example-helloworld

and the Curassow tag 0.2 (for convenience) is at

https://github.com/ragsns/Curassow/

Am I missing something or is it a bug in master branch?

Here is a simple benchmark result with wrk on my iMac 5K. Just Hello World. Compiled with swift build --configuration release. 4 workers.

~ wrk -c 1k -t 10 --timeout 5s --latency http://0.0.0.0:8000/
Running 10s test @ http://0.0.0.0:8000/
  10 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.24ms    1.02ms  10.22ms   88.24%
    Req/Sec   557.81      1.17k    6.55k    94.44%
  Latency Distribution
     50%    1.16ms
     75%    1.50ms
     90%    1.96ms
     99%    5.96ms
  3818 requests in 10.10s, 371.77KB read
  Socket errors: connect 757, read 375, write 0, timeout 0
  Non-2xx or 3xx responses: 620
Requests/sec:    377.98
Transfer/sec:     36.80KB

About half of the responses are [worker] Failed to decode data from client.

When a request is received, something seems to be sticking when accessing the body's data. It's been reproducible on 0.5.0 100% for me.

Swift Version: DEVELOPMENT-SNAPSHOT-2016-03-01-a

Platform: osx

Minimum Reproducible Example

serve { req in
    var mutable = req
    print("Body: \(mutable.body?.next())") // will never get past this line
    return Inquiline.Response(.Ok, contentType: "text/html", content: "Did Stuff")
}

Let me know if I'm doing something wrong here, everything else works, it only fails when I try to use next()

I was wondering how you approach debugging Curassow (with lldb), since it forks off worker processes at the beginning and lldb doesn't support automatic following of forks.

I found a very tedious way:

• run your server in terminal window 1
• in another window launch lldb for your binary
• run attach WORKER_PID, which is visible when the server starts
• continue as usual in the lldb instance, allowing to inspect the incoming requests in the debugger

This will obviously get untenable as a codebase grows, so I'm wondering what your thoughts on this are.

I was trying to put together a slightly less trivial demo app and realized that there was no logic yet for reading in body data. This is a first pass at implementing that behavior. It only tries to read the body if the Content-Length header is present and doesn't try to deal with Transfer-Encoding at all, but this seems to be sufficient for the basic case that I'm looking for right now.

If the body must be represented as a string (Nest spec), how would one respond with binary data? e.g. image/gif? I find myself wanting a more general representation like [UInt8], or even more general, something that can express itself as a sequence (streamable).

For instance, Ruby's Rack just wants a body that responds to .each.

Not 100% sure how the Swift PM works just yet, but if you specify minor: 1, it won't download the latest release (e.g., 0.2.3). I'm assuming minor: 1 limits us to just 0.1.x.

Came across this issue while trying to install Currasow for the first time via the Swift PM. Everything linked properly when I changed the minor version to 2.

Hello,

I've had success building a small example app with the 12-01 Swift snapshot release, but the new 12-18 snapshot release appears to break building Curassow. I'm targeting the 0.2 release of Curassow in my package file, and it's the only dependency I directly declare. Below is the results of running swift build.

I tracked this down to the SPM throwing an error in https://github.com/apple/swift-package-manager/blob/master/Sources/dep/Manifest+configureTargets.swift#L51 but I can't immediately see why this happens.

$ swift build
Cloning Packages/Curassow
Using version 0.2.0 of package Curassow
Cloning Packages/Nest
Using version 0.2.1 of package Nest
Cloning Packages/Inquiline
Using version 0.2.2 of package Inquiline
Cloning Packages/Commander
Using version 0.4.0 of package Commander
Compiling Swift Module 'Nest' (1 sources)
Linking Library:  .build/debug/Nest.a
Compiling Swift Module 'Inquiline' (3 sources)
Linking Library:  .build/debug/Inquiline.a
Compiling Swift Module 'Commander' (8 sources)
Linking Library:  .build/debug/Commander.a
swift-build: Your source structure is not supported due to conflicting directories: /path/to/project/Packages/Curassow-0.2.0

Other data:

OS: Ubuntu 14.04 (so I'm using the -b snapshot build)

$ uname -a
Linux ubuntu 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

$ swift --version
Swift version 2.2-dev (LLVM 3ebdbb2c7e, Clang f66c5bb67b, Swift 0ddf238ad7)
Target: x86_64-unknown-linux-gnu

We need public access to Arbiter.stop() in order to properly integrate as a server driver for Vapor as per https://github.com/qutheory/vapor-curassow-server/pull/1.

SPEC_FILES=$(foreach spec,$(SPECS),Tests/$(spec)Spec.swift)
// add these
LIB_FILES=$(shell ls .build/debug/*.a)
STATIC_LIBS=$(foreach lib,$(LIB_FILES),-Xlinker $(lib))

// modify your run-tests
    @$(SWIFTC) -o run-tests \
        Tests/main.swift \
        $(SPEC_FILES) \
        -I.build/debug \
        $(STATIC_LIBS)

By default, calling send on a socket which has been closed on the remote end causes SIGPIPE to be sent to the process, which terminates it. These changes change the behavior to disable the signal, and instead make send return an error code if the socket has been closed.

This situation arises frequently when deploying to Cloud Foundry, as its healthcheck process opens a connection to the app and then closes without sending any data.