JID class cache should not use one single mutex to synchronize all access on.
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:
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.
Obviously, JIRA doesn't allow me to override or remove the old patch. Please use the one that has the latest timestamp. Timestamps show up as tooltip texts - you can also view them if you hit the 'Manage Attachments' link.
Hmpfh, I've ommitted to check for null values in my previous patch. Use this one instead.
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.