ring

danm 2021-04-08T16:48:27.117200Z

Me again (sorry!). I've got the above working, in more or less the way suggested by @robertfrederickwarner. My handler now looks like this at its core:

(a/go
  (a/alt!
    respond-ch ([response] (respond response))
    timeout-ch ([_] (respond timeout-response))))
So the handler is immediately returning and delegating responding to an async process, which is what I wanted. And that seems to be working, in that if I make a curl request to the server I get my expected response. But I also get an exception from Jetty on every request, saying org.eclipse.jetty.http.BadMessageException: 500: No version. Following the stacktrace, it looks like Jetty is maybe cleaning something up so that there is no output to actually write the response to by the time my go block returns? But in that case, how am I getting my response in curl?...

robertfw 2021-04-13T22:33:04.122100Z

@carr0t Any luck figuring this out? I haven't seen that error before and nothing obvious came up on my brief search

danm 2021-04-14T08:10:29.128400Z

Yes! Sorry, I forgot to write a follow up here. I was also debugging with @weavejester via a Reddit thread, where he was very helpful (If I'm honest, he worked out the source of the issue 😉). The original problem above was that we were running an old version of Ring (1.6.0, which was the first version to have the async support). So that's entirely on me. I should have checked what version we were running (only 2 months on this project and team, still lots to understand myself), and tried upgrading. I never worked out what the actual cause in the code was, but upgrading to the latest 1.9.2 gave us a different stacktrace (and an empty response). For that, I worked out that 1.8.2 was fine, so that's what we're running for now. @weavejester worked out there was a weird incompatibility with muuntaja and Ring 1.9.0+, and I wrote up a minimal repro as an issue here: https://github.com/ring-clojure/ring/issues/436

robertfw 2021-04-14T14:59:06.129Z

Great! Glad to hear

danm 2021-04-08T17:04:47.119Z

If I wrap the a/go in a/<!!, effectively forcing it to be synchronous again and making all the other work pointless, the error goes away