Details
Improvement
Major
Description
The org.xmpp.packet.JID class contains a static Cache called stringprepCache. Access to this class is synchronized by having the cache be wrapped like this:
private static Map<String,Object> stringprepCache = Collections.synchronizedMap(new Cache(10000));
The Collections.synchronizedMap() method applies very simple synchronization, by simply synchronizing every action (even stuff like contains()) on one single mutex.
In a multithreaded environment, such as Openfire, this will significantly affect performance, as no more thread can access the cache at any given time.
Attachments
Issue Links
| This issue is related to: | ||||
| JM-1454 | Internal cache of JID class does not use a LRU based eviction policy. |
|
|
|
The patch that I'm attaching ({{
JM-1453_JID-cache-FIFO.patch}}) improves the speed of the org.xmpp.packet.JID cache by 20 to 30% in my local tests. More importantly, it significantly reduces the amount of synchronized operations.There is a drawback: it does not solve the FIFO based behaviour of the class as described in
JM-1454. Instead, it enforces it. The application of a FIFO based cache eviction policy does not require the cache to record access (based on contains() in the JID class). A LRU eviction policy would add a significant amount of logic.The patch offers thread safety suitable for the purpose of JID. It does not try to solve issues that were already accepted in the original implementation (two concurrent stringprep calculations for the same String are, in theory, possible, as the contains() and put() calls are not in the same synchronized block).
In all, although opportunities for further optimization remain, this patch should improves the existing implementation of the JID class quite a bit.
JM-1453_JID-cache-FIFO.patch}}) improves the speed of the org.xmpp.packet.JID cache by 20 to 30% in my local tests. More importantly, it significantly reduces the amount of synchronized operations. There is a drawback: it does not solve the FIFO based behaviour of the class as described inJM-1454. Instead, it enforces it. The application of a FIFO based cache eviction policy does not require the cache to record access (based on contains() in the JID class). A LRU eviction policy would add a significant amount of logic. The patch offers thread safety suitable for the purpose of JID. It does not try to solve issues that were already accepted in the original implementation (two concurrent stringprep calculations for the same String are, in theory, possible, as the contains() and put() calls are not in the same synchronized block). In all, although opportunities for further optimization remain, this patch should improves the existing implementation of the JID class quite a bit.