Re: [undertow-dev] exchange.isInIoThread()

So if everything is working correctly the only way that dispatch call would break is if the worker thread pool is exhausted somehow, which seems unlikely, as by default this should be fairly large. Stuart Bill Burke wrote: > Servlet is involved only indirectly: > > client->proxy->tomcat->proxy->tomcat > > that's the call structure. Code is here: > > https://github.com/keycloak/keycloak/blob/master/proxy/proxy-server/src/m... > > > > On 12/5/2014 9:07 PM, Stuart Douglas wrote: >> The reason why that check is there is that the authenticate call may >> involve blocking operations, which you should not do in an IO thread. >> >> Can I have a look at the code? The proxy handler will only execute in >> the IO thread, and is not really servlet aware, so I have not really >> though about how they will work together (you may need to call >> startAsync() on the servlet request). >> >> The reason for this design is that the proxy handler connects to the >> target server using the same IO thread as the original request. This >> means that there is only ever one thread involved in the proxy process, >> and we don't need to use any kind of synchronization. >> >> If the request is running in a worker thread it is dispatched back to >> the IO thread, then the proxy process takes place entirely using >> non-blocking IO in the IO thread. >> >> Stuart >> >> Bill Burke wrote: >>> I removed the isInIoThread() check in a fork of >>> AuthenticationCallHandler. Hopefully this is correct. >>> >>> On 12/5/2014 4:48 PM, Bill Burke wrote: >>>> I'm using the Undertow ProxyHandler, should I be executing the >>>> ProxyHandler in a separate thread? What I"m running into right now is >>>> that I'm making a nested HTTP call within a Servlet request ( GET >>>> http://proxy.com which invokes a call to http://proxy.com/test) and >>>> the >>>> 2nd call isn't getting through. >>>> >>>> The nested call never gets passed AuthenticationCallHandler line 46. >>>> >>>> >>> >