[the-thing]

While updating MINA 2.2.10 in QuickFIXj we encountered a deadlock in end-to-end SOCKS proxy tests.

quickfix-j/quickfixj#1347
quickfix-j/quickfixj#1348

It looks like this was introduced by #77 however all combinations of tests fail with a deadlock, which also means that there is an existing problem with org.apache.mina.filter.ssl.SSLHandlerG0 implementation.

Currently I was only able to confirm SSL + SOCKS proxy combination failures, but some of the failures in mentioned QuickFIXj PRs look suspicious. It will be easier to investigate if we solve this problem first.

Notes

• this is just a test proving there is a problem
• SOCKS proxy server was slopped out by AI, but it seems to do the thing (I'm happy to replace it with any other embedded SOCKS proxy server you can recommend - in QuickFIXj we use Netty's which would be kind of awkward to bring to MINA 👀)

[elecharny]

I'll take some time this week-end to review this fix.

Do you consider this fix serious enough that it requires a release? Seems so to me...

[the-thing]

I think this PR is stable now and I will mark it for review as soon as the sluggish ubuntu will pick up the job.

Additional deadlock flow graphs attached to JIRA.

Notes

• The bug existed for G0 handler before our patch in 2.2.10
• The fix for large SSL messages exposed the bug in G1 handler as well in 2.2.10 patch

Do you consider this fix serious enough that it requires a release? Seems so to me...

Possibly, but as mentioned for G0 handler + PROXY combination is an existing bug. We detected this in QuickFIXj end-to-end proxy test suite (we had only G1 handler covered).

[jon-valliere]

I'll check this later but I would like to caution everyone. This is the exact class of problem that was brought up two years ago that led to the experimentation branch which introduced the buggy concurrency.

[the-thing]

This is the exact class of problem that was brought up two years ago that led to the experimentation branch which introduced the buggy concurrency.

Are you referring to org.apache.mina.proxy.filter.ProxyFilter? Are there any JIRA's / PR's that you can remember related to that?

Obviously the issue is there and needs to be addressed in one way or another. Possibly causing some other, undiscovered issues in the meantime until we get it right.

My first attempt was to fix it inside G0 / G1 handlers, but I don't really want to touch G0 especially.

[jon-valliere]

This is the exact class of problem that was brought up two years ago that led to the experimentation branch which introduced the buggy concurrency.

Are you referring to org.apache.mina.proxy.filter.ProxyFilter? Are there any JIRA's / PR's that you can remember related to that?

Obviously the issue is there and needs to be addressed in one way or another. Possibly causing some other, undiscovered issues in the meantime until we get it right.

My first attempt was to fix it inside G0 / G1 handlers, but I don't really want to touch G0 especially.

I'm referring to my work in G1 and the removal of the synchronized blocks which led to #77 you brought up. G0 would never support the pattern of having an same-thread consumer blocking on the write operation because it essentially holds both the read and write locks simultaneously.

I'd appreciate a week or so for us to discuss and review the problem. I have a little bit of a time availability problem the next few days.

[the-thing]

Sure. This is more complex problem and I will not merge it without a proper review.

Have a look especially at the test + the attachments https://issues.apache.org/jira/projects/DIRMINA/issues/DIRMINA-1205 - the flow will be easier to understand.

G0 + proxy is also broken (before 2.2.10).