We're updating the issue view to help you get more done. 

Openfire queries users for disco#info after each presence change (CAPS is being polled)

Description

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?

Environment

None

Acceptance Test - Entry

None

Activity

Show:
Guus der Kinderen
January 30, 2010, 6:30 PM

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.

Guus der Kinderen
January 30, 2010, 11:34 PM

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 Niess
January 31, 2010, 12:23 AM

You are right, good finding

Guus der Kinderen
January 31, 2010, 12:23 AM

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.

Guus der Kinderen
January 31, 2010, 2:46 AM

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.

Assignee

Guus der Kinderen

Reporter

Guus der Kinderen

Labels

None

Expected Effort

None

Ignite Forum URL

None

Components

Fix versions

Affects versions

Priority

Major
Configure