vetss
commented
8 years ago 2) 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. 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.
If you have some remarks / suggestions for discussing of the best design / bugs removing, please feel free to add comments.
jaimecasero
We have now in TCAP level following locking cases:
1) we need to guarantee of storing dialogs into a dialog collection (with checking if a dialog with soem dialog id is stored or not). We need to generate available dialog IDs (this is generally a local TC transaction ID value) for creating of new local dialods.
We need to discover if this is a best way and try to remove synching of a global this.dialogs object. At the other side we need to guarantee atomic style of adding / removing / checing of dialogs and providing of a new dialogID. We are using of javolution FastMap because of it says of low access level for a collection access in case of many elemets count (I guess we need to think of values >= 100000 dialogs). But this collection does not allow multithread writing access without external synching (that we want to avoid). Possibly we can use ConcurrentHashMap without extternal blocking, we need to discover what is faster.
As for generating for available dialogID values we need to make in some cases restriction for a dialogID range, for example dialogIDs must be from 2000000 to 4000000. This is not very easy with AtomicLong instanse. We may think of suggested by Jean code for it: if(!atomicLong.compareAndSet(4000000, 2000000)) { value = atomicLong.getAndIncrement(); } else { value = 2000000; }