Parent node is always null after restarting Openfire server

Openfire Openfire Dev
1

Parent node is always null after restarting Openfire server.

Reproduction scenario:

  • create a pubsub leaf node with nodeId “myNode1” and root collection node set as parent (received via XMPPServer.getInstance().getPubSubModule().getRootCollectionNode();)

  • read the node via
    Node myNode1 = XMPPServer.getInstance().getPubSubModule().getNode("myNode1");

  • ==> myNode1.getParent() returns the root collection node

So far, everything works as expected…

  • create a pubsub leaf node with nodeId “myNode2” and root collection node set as parent (received via XMPPServer.getInstance().getPubSubModule().getRootCollectionNode();)

  • stop the Openfire server

  • start the Openfire server

  • read the node via
    Node myNode2 = XMPPServer.getInstance().getPubSubModule().getNode("myNode2");

  • ==> myNode2.getParent() returns null

Problem is the same as described in Error loading the parent of LeafNodes

The getParent() checks parentIdentifier which is null because it is only set in the constructor and not when changeParent() method will be called (which is the case after the nodes will be loaded from database during Openfire start).

2

Is this the same? Bug in PEP Service, updates to nodes are not pushed to roster contacts - #2 by guus

3

Thanks for reporting this. I think you’re right: when the ‘parent’ field of Node instance is updated, its parentIdentifer field should always be updated. That’s not happening in the changeParent class. I have raised a new issue for this problem: [OF-2401] - Ignite Realtime Jira. I’ve proposed a fix in https://github.com/igniterealtime/Openfire/pull/2008. Are you able to test this fix?

I believe I’ve identified another issue with that code. I’ve not yet fixed that, but flagged it as OF-2402.

4

Thanks for filing the issue.
Some more clarification:

5

Yes. I’ve now updated the PR to include that change. Good catch, thanks.

6

Unfortunately, I currently don’t have the possibility to verify the fix. But the PR looks good to me.