Wow! Thanks for the super-fast reply.
I think I'm a little confused about the difference between being in an IO thread and being dispatched. Is it the case that if the server thinks I'm "not dispatched" (that is, if the server will send a response on my behalf when my method returns) that I'm always on an IO thread? I often do some work on my own thread pools and those threads often interact with the HttpServerExchange object. I know that some interactions with the exchange object (e.g. recieveFullBytes) will take an exchange that is in a dispatched state and put it in a non-dispatched state. So I want to just keep checking that I'm dispatched and, if I'm not, dispatch again. So my code might look something like:
void handle(HttpServerExchange exchange) {
exchange.dispatch(myOwnThreadPoolExecutor, () -> {
log.info("I am not not on an IO thread and I am dispatched.");
doSomethingWithExchange(exchange);
assert exchange.isDispatched();
assert !exchange.isInIoThread();
// how do I check to see if I'm still in a dispatched state?
});
}
(note: the above is a bad, super-simplified example and in the actual code there's a lot of asynchronous stuff happening that bounces the execution from one thread pool to another).
The reason for all of this is that I have some edge cases which appear to be race conditions in which I know for sure that I call exchange.dispatch() and then I start doing some work but the exchange gets ended before I've finished my computations and have a response to send leaving the client with an empty response. I'm not entirely sure how that could happen, but my best guess right now is that I interact with the exchange in some way that causes it to no longer be in in the dispatched state and, as a result, the HttpServerExchange is ending the exchange for me before I'm ready.
Thanks again,
Oliver