After a user changes its presence, Openfire queries the user for Service Discovery, every time.
One such query is expected: the CAPS verification string needs to be calculated / verified. Apparently, Openfire keeps asking for the corresponding features/identities for every VER string it gets.
Through debugging, I've noticed that the VER string that Openfire calculates based on the response to the disco#info request, does not match the VER string that was in the original presence that the user sent out. This happens for at least two clients: Pidgin and Gajim.
Is the verification calculation in Openfire correct?
Guenther: the entity that sends the presence stanza (alice, in your example) will be queried by the server for disco#info (typically a few seconds after the stanza was sent). I can reproduce this in Pidgin.
I've fixed the issue locally. The hash calculation in Openfire didn't take all of the fields into account that it should. I will clean up the code and commit it later today.
I am removing the "Entity Capabilities Pending Hashes" cache. It is extremely unlikely that a response to an IQ query that has been send by a server node is received by another cluster node. This might occur if the original server node crashes after sending the request. If this does happen, another server node will simply ignore the result. The VER string won't be resolved during that attempt, but this doesn't impact users much. The VER string will be resolved after the next presence change.
The minute impact does not validate the rather large overhead of maintaining a clustered cache. It will be replaced with a local map.
You are right, good finding
A new implementation of CAPS has been committed. I'll spend some more time to remove other clustered caches, as those are adding overhead rather than preventing resource usage too.
Actually, let's not. It'll force us to seriously review eviction policies. I'd rather not mess with that just before the upcoming release.