This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (41)
- # boot (38)
- # cider (17)
- # cljs-dev (52)
- # cljsjs (3)
- # clojure (200)
- # clojure-italy (8)
- # clojure-russia (50)
- # clojure-spec (28)
- # clojure-uk (45)
- # clojurescript (28)
- # core-async (9)
- # core-matrix (2)
- # cursive (16)
- # datascript (15)
- # datomic (50)
- # dirac (5)
- # emacs (20)
- # figwheel (8)
- # flambo (2)
- # hoplon (10)
- # incanter (1)
- # jobs (1)
- # leiningen (2)
- # lumo (26)
- # mount (171)
- # off-topic (22)
- # om (54)
- # onyx (2)
- # pedestal (27)
- # re-frame (10)
- # reagent (12)
- # ring (27)
- # ring-swagger (3)
- # rum (2)
- # slack-help (1)
- # spacemacs (134)
- # specter (6)
- # sql (15)
- # testing (20)
- # uncomplicate (5)
- # unrepl (49)
- # untangled (9)
- # yada (29)
@weavejester yes I have. Thought maybe it was some idle ware getting in the way. I even tried a bare bones ring app. Don't know what I could be missing.
@juliobarros Just a wild thought: have you confirmed that a rogue version of Ring isn't being pulled in?
@seancorfield no. I didn't check for that. I'll look again with a clear head in the morning. Thanks.
First time I've tried the async handlers in Ring... works fine as long as I only call
respond to return normal responses. If I call
raise, that first request completes (with a server 500 error as expected)... but then no further requests work and I see thread death exceptions in the console log. I can't find a tutorial for the async version of Ring to see if I'm doing wrong...
@seancorfield It’s possible that might not have been tested, especially if you’re not using
wrap-stacktrace or some other form of middleware that catches the error. I’ll look into it.
I added some tests (https://github.com/ring-clojure/ring/commit/4b5423336f8b948620a9dffb295aff551055499f), but maybe you’re doing something I haven’t thought of, or there’s some combination of middleware that’s messing up somehow.
If you can give me something reproducible @seancorfield, it would be a lot of help 🙂
Thanks for the repo. Unfortunately I can’t reproduce the error, even with the repo! What O/S and Java version are you running it under?
Specifically on Mac OS X
java version "1.8.0_31" Java(TM) SE Runtime Environment (build 1.8.0_31-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)
Pretty sure on W10 I’ve tried it both natively on Windows and also via WSL (Ubuntu).
Hm, odd. I’m using MacOS and Java 8 as well. Let me try upgrading to the exact version you’re using, and wiping out my .m2 directory just in case there’s something there that’s making it work for me.
LMK if there’s additional debugging I can do for you based on that repo. It’s 100% reproducible for me on every platform so far 🙂
Thanks. I’m going to try and reproduce it on my machine first. So far no dice. I’ve wiped out my .m2 directory and it still works fine. Going to try upgrading the patch version of Java.
I am seeing some weirdness in the logs, however. It might be related to
The Javadocs for
.sendError say "After using this method, the response should be considered to be committed”, but maybe that doesn’t mean the response actually is committed, and therefore
.complete should still be used.
Okay, I think I might know why it’s failing. Can you try adding
[weavejester/ring-jetty-adapter “1.6.0-SNAPSHOT”] to your dependencies and see if that code works?
Great! I’ll release RC3 in a little while. It looks like I misinterpreted the Javadoc for the
.sendError method, or else it’s misinterpreted by Jetty! In either case, it shouldn’t hurt to add a