Fork me on GitHub

@juliobarros Have you set the adapter to :async? true?


@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.


Hm, I’m not able to reproduce the error, I’m afraid.


I added some tests (, 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 🙂


@weavejester Here’s a minimal repo showing the problem I ran into — not sure if it’s a bug or user error 🙂


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?


I repro’d on both Mac OS X, Java 8, and Windows 10, Java 8.


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)


Roughly the same on W10 but I can check for sure if you need it.


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.


Oh, another thought strikes me: what are you using to test it? curl?


Updated Java, still no error...


I am seeing some weirdness in the logs, however. It might be related to .sendError and .complete.


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?


Just tested — that seems to fix it! Excellent!


I gather an updated ring/ring-jetty-adapter release is in our near future? 🙂


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 .complete after .sendError.


Sure. I'm on vacation but will try to remember on Monday. I have a minimal example with just wrap-params and wrap-keyword-params and nothing else.