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.

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.

You are right, good finding

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.

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.