Pubsub Problem - Recursive Tree after Publishing

Openfire Openfire Support
1

Hello,

I’ve been trying to get a simple use case up, demonstrating the standard create node using default configuration and a publishing of a simple item (using an example from the XEP-0060 standard). My IQs are as follows:

<iq type=‘set’

from=‘rise@folka’

to=‘pubsub.folka’

id=‘create01’>

<pubsub xmlns='[http://jabber.org/protocol/pubsub](http://jabber.org/protocol/pubsub)'>

<iq type=‘set’

from=‘rise@folka’

to=‘pubsub.folka’

id=‘publish01’>

    <entry xmlns='[http://www.w3.org/2005/Atom](http://www.w3.org/2005/Atom)'>
Soliloquy

To be, or not to be: that is the question:

Whether 'tis nobler in the mind to suffer

The slings and arrows of outrageous fortune,

Or to take arms against a sea of troubles,

And by opposing end them?

 <link rel='alternate' type='text/html' 
            href='[http://denmark.lit/2003/12/13/atom03'/](http://denmark.lit/2003/12/13/atom03'/)>

tag:denmark.lit,2003:entry-32397

2003-12-13T18:30:02Z

2003-12-13T18:30:02Z

After the final IQ however, my leaf node: “clean_test1” will have a child of the root pubsub service, and it will follow recursively. Meaning I will see root -> clean_test1 -> root -> clean_test1 -> root -> clean_test1, infinitely. Does anyone have an idea why this would be? I get the expected iq return packets to the above, insofar as they match the spec and return no errors.

I am using a simple third party tool to send the XML directly to the server, but I have seen the same behavior using a 3rd party xmpp library as well, which supports pubsub operations.

2

Well, that is a pretty simple use case and that behaviour hasn’t been seen before. How are you determining that the recursive tree exists?

For your test case, are you simply sending those two stanzas? Are they being sent concurrently or consecutively? I would like to try and duplicate this problem.

3

Thanks for the response. The above stanzas were sent consecutively (I have since renamed my node to /clean_test1 in my test cases). I’ve tested browsing the tree with the Service Discovery tool in PSI. At first I thought it was perhaps an error in the metadata which would potentially cause an infinite loop, however I suspect I’m more the victim of a potential bug in the tool itself. I have begun sniffing the stanzas that come in and out, and this appears to be the cause of the recursion:

SEND:

RECV:

SEND:

RECV:

SEND:

RECV:

And this will continue to go on infinitely. My question at this point is in this particular stanza:

RECV:

I do not know what that item is in my /clean_test1 node, nor where it came from. At the very least, it’s certainly not a node so I think this is specifically a problem with PSI and it looks like my code tripped upon the same exact bug so I’m fairly confident it is not an openfire issue.

[edit] I was able to fix the recursion by isolating a bug on my end. And I do believe that item I was curious about is in fact the published message from my opening post.