Re: MINA's OrderedThreadPoolExecutor has queued work, but no workers

2022-01-12 Thread Emmanuel Lécharny
On 12/01/2022 13:47, Guus der Kinderen wrote: Hi Emmanuel, Thanks for your speedy reply. I have created an issue as you requested: https://igniterealtime.atlassian.net/browse/OF-2367 In your email, you're writing that the exception

Re: MINA's OrderedThreadPoolExecutor has queued work, but no workers

2022-01-12 Thread Guus der Kinderen
Hi Emmanuel, Thanks for your speedy reply. I have created an issue as you requested: https://igniterealtime.atlassian.net/browse/OF-2367 In your email, you're writing that the exception seems to be due to some TLS handshake. How did you come to that conclusion? You might very well be right, but

Re: MINA's OrderedThreadPoolExecutor has queued work, but no workers

2022-01-11 Thread Emmanuel Lécharny
Hi again, my bad, if we get an exception during the runTasks execution, we won't exit the for(;;) loop, so this is plain normal to have an idleWorkers.incrementAndGet(); in the finally part. There are two places where we exit the loop: - if we exceed the number of workers - when session ==

Re: MINA's OrderedThreadPoolExecutor has queued work, but no workers

2022-01-11 Thread Emmanuel Lécharny
Hi Guus, I agree there is some inconsistency, and I need to check why. Regarding the initial pb, it seems like an exception causes the worker to be removed, and this exception seems to be due to some TLS handshake failure. I suspect that TLS 1.3 is being used on the client side, which is

Re: MINA's OrderedThreadPoolExecutor has queued work, but no workers

2022-01-11 Thread Guus der Kinderen
Although I'm not sure if this is the source of my issue, I can reproduce the state by creating a unit test that causes a RuntimeException and/or Error to be thrown by a filter that is processing an event. In OrderedThreadPoolExecutor's Worker, this snippet causes the Worker to be removed, but the