<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Jul 16, 2018 at 12:16 PM Stan Rosenberg &lt;<a href="mailto:stan.rosenberg@gmail.com">stan.rosenberg@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:small">On Sun, Jul 15, 2018 at 9:48 PM, Stuart Douglas <span dir="ltr">&lt;<a href="mailto:sdouglas@redhat.com" target="_blank">sdouglas@redhat.com</a>&gt;</span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>If all you want to do is drop the connection then just scheduling a task that does exchange.getConnection().close() is fine, no HTTP response will be returned to the client.</div></div></blockquote><div><br></div><div><div style="font-size:small">That would imply <span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">exchange.getConnection().</span><span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">close() is thread-safe; just double-checking.</span></div></div></div></div></div></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>If you want to actually send a response to the client then you are going to have to have some kind of lock/CAS that prevents your application from writing once the timeout has taken effect. </div><div><br></div></div></blockquote><div><br></div><div style="font-size:small">​Makes sense, but that&#39;s custom logic; i.e., not available in the API, right?</div></div></div></div></blockquote><div><br></div><div>Yes. The issue with including something like this in the core API is that every request has to pay the thread safety price even if they don&#39;t use it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div style="font-size:small"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>Are you using the Servlet API or the HttpServerExchange API? The best way to approach this is a bit different depending on what you are doing.</div></div></blockquote><div><br></div><div> <span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">HttpServerExchange API<div style="font-size:small;display:inline">​. Thanks!​</div></span></div></div></div></div></blockquote><div><br></div><div>This is a bit harder to do in the general case. With Servlet you could just create a thread safe wrapper, where the wrapper basically disconnects from the underlying request on timeout. The Undertow native API is not designed around wrapping though, so it needs cooperation from the application to manage this.</div><div><br></div><div>If you know the application is only going to be writing data (and not setting headers) then you should be able to make this work via a ConduitFactory implementation that handles the locking, although if this is not the case then you are going to need some kind of external lock.</div><div><br></div><div>Stuart</div><div><br></div><div><br></div><div><br></div><div> </div></div></div>