If a user has multiple subscriptions to the same pubsub node with different full JIDs (user1@domain/foo and user1@domain/bar) each client will receive multiple event/item notifications. It appears as if openfire is just sending the item notifications out based on a matching bare JID which causes duplicate notifications to be sent to clients that dont have a matching resource id. This increases with number of different resource IDs a user has logged in and subscribed with.
Why is this a problem? What if a client application appends a timestamp to the resouce ID so it is unique on every login. The number of event notifications will be compounded and increase by one after every login.
Here is the section of the XEP I’m referring to: http://xmpp.org/extensions/xep-0060.html#subscriber-subscribe-multi
Specifically this statement: “; however, if the same bare JID has multiple subscriptions but those subscriptions are for different full JIDs (e.g., one subscription for user@domain.tld./foo and another subscription for user@domain.tld/bar), the service MUST treat those as separate JIDs for the purpose of generating event notifications.”
How to test this:
Create a pubsub node.
Subscribe to the node as user1@domain/foo.
Subscribe to the node as user1@domain/bar.
Login as client user1@domain/foo.
Publish an item on the node and notice you get two notifications under the client user1@domain/foo.
Is this a bug in openfire or am I understanding the spec wrong?
Thanks,
Mark
To accomplish JID-based subscriptions, I think you will want to set the following system property:
xmpp.pubsub.multiple-subscriptions=false
Setting this property will inform Openfire that you wish to separate the pubsub “channels” based solely on the subscriber JID and will then constrain delivery of the event notifications to the user via the corresponding full JIDs. Note however that if you are using this approach and also generating a random resource for the subscribing JID, you will want to ensure that each subscription is properly canceled (via unsubscribe) when the user logs off the system.
By default the module is configured to manage subscriptions based on a subscription ID rather than a unique JID. When multiple subscriptions are enabled (xmpp.pubsub.multiple-subscriptions=true), each subscription request, event notification and unsubscription request must include a “subid” attribute to distinguish among the various pubsub affiliations for the user. In your case you might prefer to associate the subscription to the user (regardless of resource) and share the corresponding subid among the various logged in sessions for that user.
Tom,
Thanks for the reply but this does not fix the issue. I have aleady tried setting:
xmpp.pubsub.multiple-subscriptions=false
What this actually does is stop multiple subscriptions being created for the same full JID.** It still allows multiple subscriptions to be created for the same bare JID (with different resource IDs) and all clients w/ the same bare JID will receive the extra notifications (even if the resource IDs dont match). **
As I understand it xmpp.pubsub.multiple-subscriptions (in openfire) only controls the ability to create multiple subscriptions for the same full JID. If this is set to true it will allow duplicate subs for the same full JID. The spec then specifies that the subids must be used and the duplication items should be sent in one notification containing all items that have the subids set.
-Mark
This is a known bug (OF-14). This wasn’t clarified in the spec when the original code was written and has not been updated since the spec was changed.
Thanks for the clarification Robin. I have updated the ticket with a link to this thread. We will need to take a deeper look at this to determine if we can make changes to comply with the current spec without breaking existing functionality.
[copied from JIRA ticket]
It appears that the current implementation presumes that a subscription must exist for any owner and/or publisher, and as a result will try to create a subscription if one does not already exist for the corresponding bare JID. This has the unfortunate side effect of creating implicit subscriptions (using the bare JID) for all owners and publishers. We believe this is the root cause of the unnecessary (and undesirable) additional notification deliveries.
I have checked the current specification (XEP-0060) and see no mention of a “subscribed” post-condition for either node creation or node affiliation change(s). I am proposing that we remove these extraneous subscriptions and only deliver item notifications for active subscriptions that have been explicitly created.
Thoughts/comments?