[OF-339] Openfire queries users for disco#info after each presence change
(CAPS is being polled) Created: 01/29/10 Updated: 01/31/10 Resolved: 01/30/10
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Resolved
Openfire
Core
3.6.4
Type:
Reporter:
Resolution:
Labels:
Bug
Guus der Kinderen
Fixed
None
3.7.0 beta
Priority:
Assignee:
Votes:
Major
Guus der Kinderen
0
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?
Comments
Comment by Guenther Niess [ 01/30/10 ]
Hi Guus, with Pidgin, I can't reproduce this:
(10:13:41) jabber: Sending (ssl) (alice@domain.lt/Pidgin):
<presence>
<priority>1</priority>
<c xmlns='http://jabber.org/protocol/caps' node='http://pidgin.im/'
hash='sha-1' ver='AcN1/PEN8nq7AHD+9jpxMV4U6YM=' ext='voice-v1 camera-v1
video-v1'/>
<x xmlns='vcard-temp:x:update'><photo/></x>
</presence>
and
(10:13:41) jabber: Recv (ssl)(304):
<presence from="alice@domain.lt/Pidgin" to="bob@turing.domain.lt">
<priority>1</priority>
<c xmlns="http://jabber.org/protocol/caps" node="http://pidgin.im/"
hash="sha-1" ver="AcN1/PEN8nq7AHD+9jpxMV4U6YM=" ext="voice-v1 camera-v1
video-v1"/>
<x xmlns="vcard-temp:x:update"><photo/></x>
</presence>
Maybe I should look on this in more detail.
Comment by Guus der Kinderen [ 01/30/10 ]
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.
Comment by Guus der Kinderen [ 01/30/10 ]
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.
Comment by Guenther Niess [ 01/30/10 ]
You are right, good finding
Comment by Guus der Kinderen [ 01/30/10 ]
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.
Comment by Guus der Kinderen [ 01/30/10 ]
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.
Generated at Tue Feb 09 23:50:05 CST 2016 using JIRA 7.0.10#70120sha1:37e3d7a6fc4d580639533e7f7c232c925e554a6a.