|
From: Steve B. <st...@te...> - 2007-05-23 15:05:28
|
> 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 |