JID class cache should not use one single mutex to synchronize all access on.
Description
Environment
Attachments
is related to
Activity
Guus der Kinderen September 1, 2008 at 8:21 PM
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.
Guus der Kinderen September 1, 2008 at 8:19 PM
Hmpfh, I've ommitted to check for null values in my previous patch. Use this one instead.
Guus der Kinderen September 1, 2008 at 1:54 PM
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.
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 likecontains()) 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.