Re: [Quickfixj-users] A deadlock while using the SSL

[Steve B. <st...@te...>]

> As far as I can see, there is a high probability of having similar
> deadlocks in other parts of the filter chain when using the SSLFilter. The
> problem can be solved by changing the synchronization model for the
> quickfix.Session class. I understand though that this task is rather
> complex and time consuming. Do you see other ways of solving this? Please
> advise, I am willing to contribute if necessary.

Hi,

Thanks for the detailed information. I've actually done some significant
redesign of the synchronization strategies for the next release. Like you
said, it makes verification of thread correctness more difficult but the
current approach is too prone to deadlocks. The basic strategy for the
sync redesign is to be sure there are no active quickfix.Session locks
when an application callback is invoked or the communication layer (MINA)
is accessed. I can test this with the acceptance tests by evaluating
active locks during each quickfix.Application callback and ensuring the
session is not locked. It's a little trickers for the MINA locks, but I
think it's clean. All tests are passing, but unfortunately bugs related to
locking can be nondeterministic.

I also don't allow setting the DataDictionary on a quickfix.Session. The
data dictionary is typically supplied when the Session is created. The
ability to modify the DD reference in the session meant that access had to
be synchronized or the reference had to be volatile. I've now made the
reference final so avoid the related synchronization. This means the
setDataDictionary() method is now unsupported (unlike in the QF JNI). If
that's a problem for anyone, I'll reconsider the current approach. I
can also add a dedicated lock only for the data dictionary reference.

Steve