[undertow-dev] exchange.isInIoThread()

[Stuart Douglas]

I don't see this, the test is passing for me and the correct data is 
being returned.

I am trying to think of what could cause the situation you describe. One 
would be that if an earlier handler ends the exchange but then calls the 
next handler anyway with an exchange that is already done.

Another would be that if there was another thread involved somehow.

Without being able to reproduce it locally it is hard to say for sure.

Stuart

Bill Burke wrote:
> In ProxyServerBuilder line 228 change ProxyAuthenticationCallHandler to
> Undertow's AuthenticationCallHandler.
>
> Test:
>
> https://github.com/patriot1burke/keycloak/blob/master/testsuite/proxy/src/test/java/org/keycloak/testsuite/ProxyTest.java
>
>
> Run testHttp()
>
> You'll see that ProxyTest line 127 returns 200 with empty data. If you
> run in debugger you can see isInIoThread() check executing in the
> AUthenticationCallHandler.
>
> On 12/7/2014 4:12 AM, Stuart Douglas wrote:
>> In your case I think it is, as your IdentityManager won't block (it is
>> always safe, its just that perf might suck in some cases).
>> I would still like to get to the bottom of this though, how do I
>> reproduce this?
>>
>> Stuart
>>
>> Bill Burke wrote:
>>> So removing the isInIoThread() check is ok?
>>>
>>> On 12/5/2014 9:26 PM, Stuart Douglas wrote:
>>>> 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/main/java/org/keycloak/proxy/ProxyServerBuilder.java
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>