Bugs and upgrades to Pubsub implementation

This is a list of defects I have encountered in using the pubsub features of OpenFire. While some are definite defects, many are probably due to changes in the spec between 1.8 and 1.12. I encountered these while writing a pubsub client library, and since I only had version 1.12 to go by, that is what I made the library compatible with.

I have included fixes (and upgrades) to resolve some of these which helps bring the implementation up to the 1.12 version of the specification. I would have liked to do a complete job (in upgrading) but I don’t currently have time to address all the issues.

  1. An error occurs if request to get items from a node is called without and subscription id. The subscription id is only required if there are multiple subsriptions. (http://xmpp.org/extensions/xep-0060.html#subscriber-retrieve-error-subid) Status - Fixed
  2. Getting a specific list of items from a node has an error in which it copies the input list into the result and then retrieves the results from the node. Thus the reply is double the size with each item appearing twice, once without the payload and once with. This also results in requests with max_items set to return that attribute in the result as well. (Location - LeafNode:sendPublishedItems - copies the request items element into the result) Status - Defect
  3. Request to get node subscriptions retrieves subscriptions for all nodes. (Location - PubSubEngine:getSubscriptions - Doesn’t check for ‘node’ attribute). Status - Defect
  4. Subscription items include and ‘affiliation’ attribute which is not in the schema. Status - Defect or Upgrade Required
  5. Attempting to retrieve subscriptions for a node will fail when there was no subscription id specifed in the request, even though the user only has 1 subscription. This should work if there are not multiple subscriptions.Status - Fixed
  6. Cannot retrieve options for for subscription if from and subscriber jid don’t match. Only the bare jid should have to match. Status - Defect
  7. Event message with SHIM information holding multiple subscriptions should have the name=‘SubID’, not ‘pubsub#subID’ as it is currently. Status - Defect or Upgrade
  8. Delay information on published item uses incorrect schema. Probably a version upgrade. Status - Fixed
  9. Publishing multiple items at once causes an exception on the server due to add() not being supported on the List returned from Arrays.asList(). Status - Fixed
  10. On node configuration, the configuration event published to subscribers contained an item element with an id=‘configuration’ instead of a configuration element. Probably a version related issue. Status - Fixed
  11. Subscription owner should be the jid as supplied, not the bare jid. The spec says that nay jid should be able to be used. Currently all subscriptions are stored using the bare jid as the owner. Status - Defect
  12. Request for subscription options returns an invalid reply. The ‘option’ element should not have a namespace and should contain a form. Status - Defect or Upgrade
  13. Persistent nodes will not store items unless the max_items is set. Otherwise, it will check for size greater than -1 (unset max number) and never persist. Status - Fixed
  14. Posting multiple items with the same ID will cause a new ID to be generated for the item instead of overwriting the item. Status - Fixed
    LeafNode.java (20542 Bytes)
    Node.java (87665 Bytes)
    NodeAffiliate.java (12853 Bytes)
    PubSubEngine.java (88215 Bytes)

Hi,

Do you have a Jira account? If so, I can provide you some access to properly file these there.

Thanks!

daryl

No, I don’t, so that would be great.

Thanks!

Hi,

Please create a Jira account first: http://www.igniterealtime.org/issues/secure/Dashboard.jspa

daryl

Account is created, but I cannot create a new item.

Hi,

You should be able to now.

daryl

I’ve tried to fix the 3rd issue (PubSubEngine:getSubscriptions) as follows (see the codes in red):

private void getSubscriptions(PubSubService service, IQ iq, Element childElement) {
    // TODO Assuming that owner is the bare JID (as defined in the JEP). This can be replaced with an explicit owner specified in the packet
    JID owner = new JID(iq.getFrom().toBareJID());

    // @william: "node" attribute specified in "<subscriptoins node='xxx'>" ?
    String nodeID = childElement.element("subscriptions").attributeValue("node");

    // Collect subscriptions of owner for all nodes at the service
    Collection<NodeSubscription> subscriptions = new ArrayList<NodeSubscription>();
    for (Node node : service.getNodes()) {
        if (nodeID == null || nodeID.equals(node.getNodeID()))  // @william: only collects specified node
          subscriptions.addAll(node.getSubscriptions(owner));
    }

A patch for that defect is already attached to the JIRA task. Pretty much the same as you coded it . The code included with the original post of this thread is not all up to date anymore. Patches have been created for most of the tasks and are already in JIRA, waiting to be committed.

Robin

Hey Robin,

I’m now looking into this so we can turn the page. Do you happen to have the list of jira issues so I can use the latest version of your patches?

Tks,

– Gato

I found the following issues:

OF-17

OF-5

OF-16

OF-7

OF-20

OF-12

Checking them now.

– Gato

So far I checked OF-17 and OF-5 and both look great to me so can be checked in. Gotta go to a meeting now but will continue checking the remaining jira issues.

Tks,

– Gato

I’m done reviewing those patches. They are all fine and can be checked in. OF-20 is the only one where I asked if the spec was modified so that the attribute “affiliation” no longer exists. If that is the case then all changes can be checked in.

Tks,

– Gato

I added the appropriate schema from the spec as a comment to the task to show that the field no longer exists.

Hi Gato and Robin,

Great new Pubsub code . How are the chances that it will make it into OF 3.6.5?

Many thanks

Michael

I expect it will be, as soon as I have my vacation done and computer problems rectified. Of course I don’t actually know what the release date is yet, but I am assuming I will have time to commit the actual defects at least. Perhaps do the spec upgrades as well.