Thanks @Oleg-Afanasiev for the report and contribution !

Can you please sign the contributor license agreement at http://www.telestax.com/open-source/#Contribute and also do a formal pull request as decribed in our Open Source Playbook ?

Hello @Oleg-Afanasiev,

Let's continue discussing in #110.
We need to have the best solution for it.

have you consider using FastMap.shared API as in concurrentHashMap, trying to leverage putIfAbsent?. The fix involves a system/stack level lock to protect the "getPreviewDialog" where the actual write happens, this may introduce high thread contetnion(consider reducing the scope of the lock for both the sync object and the code block).

Hello @jaimecasero

we used FastMap for much time trying to achieve max productivity (as FastMap declares very high scalabiliy) by usage of locking for writing and reading without locking. But as for now we have confirmations that there are collisions there.
Usage of FastMap.shared() (as for its description) will not fix that collision problem. And "putIfAbsent()" we have not tried, I have no idea how it may help us.
I am thinkg of leverage of ConcurrentHashMap collection and remove our synch() blocks for them.

As for a suggested fix, I do not like such big synch() blocks too.

ConcurrentHashMap collection==FastMap.shared() -> the key of these concurrent collections is not the implementation (i agree using shared alone will not make any difference), but the additional API exposed. If you dont use the "putIfAbsent" method from a ConcHashMap/shared, instead of regualr "put" there wont be much difference (that true even for CHM).
The magic of putIfAbsent is that the key presence check is done atomically inside the collection impl.

Also there are new features in Java8.computeIfAbsent or Guava.MapMaker collections that may be worth visitins to prevent the systemWide lock, as explained in:
http://stackoverflow.com/questions/3752194/should-you-check-if-the-map-containskey-before-using-concurrentmaps-putifabsent

Hello @jaimecasero @Oleg-Afanasiev

thanks for raising an issue and discussing of it. I have committed updates for the described problem. Please check commits list in #110. I have tried to remove of synchronized() blocks and switched instead of it to ConcurrentHashMap that may help us in collisions.
Updates are committed into master branch.

@Oleg-Afanasiev , can you please check the code at your tests for checking if a problem is fixed or not.