vetss
commented
7 years ago New nonBlocking threading model - we will process all tasks in nonBlocking mode and any TCAP dialog will be assigned for a concrete threads. It may be done for example by algo when we have 10 threads and a dialog X will be assigned to the thread Y depending on the last digit of dialogId - thread affinity. This means that we do not need any dialog level synch() blocks more. But this approach means some compecticity for user because if a user ask TCAP / MAP / CAP stack to do something (send a message), then stack will not do it immediately in sycj mode but just schedule the sending task for future for some thread scheduler. And a user will not get a result but will have to listen some Future object success or failure events. A success result event may have some result info like invokeId that is needed for a user. Interfaces in this case will look like: Future send(TCBeginRequest event); Future addInitialDPRequest(...); Future send(); So no return results and not Exceptions. A user must sign for Future object for listening of success / failure events. This approach needs user application changing and (I think) RAs changing by adding of events of operations results results. This approach demands also significant code changing. We need to decide if we will make this now or later.
guyhhu
The second locking using - blocking of a Dialog instanse to guarantee some processing as atomic. The example is - we can jave two different events, one from a SS7 peer (TC-CONTINUE primitive has come), another from a local TCAP user (he wants to send some other message to a peer). We need to make the second processing only after the first one is finished. For this DialogImpl has now "ReentrantLock dialogLock = new ReentrantLock();" object that is locked before any action.
I am thinking of another possible solution - Threadaffinity. We can run both events types (from peer and from a local user) in one dedicated for a concrete Dialog thread (as it is done in netty). Dedicated means that we have a thread pool that processes TCAP events processing. But for a concrete dialog only one of those therads from the pool can be used. In this case actions from a TCAP user will be processed in these threads and not in threads of a TCAP user.
This new approach demands of major interface changes. If only asynch involing will be supported then no message processing results / Exceptions will return to a message sender (TCAP stack user). A user have to monitor results of Future objects.
Check also comments in issue: https://github.com/RestComm/jss7/issues/110