Hi,
I am writting a flex XMPP client using XIFF and OpenFire. I would like my client to connect to the server and automatically find all the services that are running the MUC protocol and then retrieve the list of rooms for each.
I am using the getServiceInfo() method in the Browse class to get the features of each service running on my server. To do this I am looping over an array of the service JID’s, so in my array are the JID’s pubsub.192.168.50.29, conference.192.168.50.29, proxy.192.168.50.29, search.192.168.50.29 etc… (this array is populated by calling getServerItems() on the server JID)
This is not a problem that is issolated to my jabber server, I have the same issue if I connect to a public server… although strangly, ‘distance’ between the client and server seems to make the issue worse??
Has anyone else experianced this problem? Is it due to the number of IQ requests I am sending in such a short time?
The problem I am having is that although the XMPPConnection is writing all the IQ requests to socket, the socketDataReceived() method is only being called for some of the requests. The number of responses that comes back from the server seems to be random, some times they all do (rarely) and other times just a few or one!?
Ok, I have found a fix for this and that is to queue the getServiceInfo() requests so that only when the reply from the previous request is returned does it then move on to the next request.
Is the behaviour correct? I would have thought that the OpenFire server would be threaded and be able to cope with multiple IQ request without failing… as shouldnt every IQ request always receive a result response?
The IQ has an ID for this use, set/get which is replied with a response from the server.
So the multi threading should be possible.
Do you have suggested fix or a patch if possible?
The ‘fix’ I have implemented is on the client side, and could be added to the XMPPConnection class, after a bit of optimization. The only problem I can see is that it could potentially slow down IQ requests, as it would process one at a time, and would only move on when the result from a request was returned. This isn’t really an issue when querying your home server, but it you where doing queries on other remote servers then it could ‘hang’ the IQ requests until the results where returned.
As for a server side fix, my Java is not good enough to implement a multi threaded fix, although it would be nice to see if this would resolve the original problem I reported above, thereby removing the need to queue IQ request on the client side.