XMPPBoshConnection polls too early currently, before it has processed the responses and queued up any new requests for sending. This results in too many messages being sent to the server (e.g. sends poll message, then processes responses, then immediately sends more requests). This can actually result in erroneous behavior – I noticed with Tigase that XIFF was sending the poll when receiving the stream features from Tigase, and Tigase would return with another stream features message, causing 2 separate sessions to eventually be set up.
This patch fixes that by moving the call to pollServer from onRequestComplete to the end of processResponse, so that we can then check to see whether we should poll based on the number of outstanding requests and the length of the request queue.
Comments and feedback welcome, especially acceptance tests against your server deployment.
I was talking about the problem that I describe here in a topic that I finally decided to post… because I can’t find any solutions (for now)
We have a Flex API for our application that is both used in a Flash version and in an AIR version. It works great in the Flash version but with AIR, I continuously and randomly get disconnected from eJabberd for reasons I cannot still well defined.
I know that when I get disconnected, the code is going through the IOErrorEvent handler method and so I discovered that the error message was related to a classic #2032 Flex Player error.
Of course, there is no reason why the BOSH URL could not be found whereas I successfully connect and login to eJabberd a few seconds before. And by searching the web, I read some articles about HTTP polling issues with Flex / AIR.
But then I added some event listeners to trace HTTP status and discovered that the error occured with a 502 HTTP error code. By still searching the web, I found that it was a proxy issue (and I’m using a proxy configuration to resolve crossdomain issues). So maybe my Apache configuration is not exactly perfect (but still works for the Flash / website version of our application and not for AIR ? What… ?)
Finally I think there may be an issue with XMPP messages. Maybe some could be received too earlier and something like that but I don’t know at all.
Does the latest version of the code result in any different behavior for you?
Can you trace the messages being sent for your HTTP session with ejabberd on AIR and post them here? Is the session even being established (e.g. the first message being sent successfully)? Or is it randomly disconnected later on?
EDIT: I see you outputted logs from ejabberd in the other thread. I mean output traffic logs from XIFF by adding event listeners to XMPPConnection for IncomingDataEvent and OutgoingDataEvent.
Concerning XIFF traces, it displays an official Apache HTML source of a 502 proxy error page as incoming data and so I have an exception in parseXML after that.
So now I’m sure it’s a proxy problem, that occurs only with AIR.
But sometimes I receive 404 error too but I think it’s a timeout issue or something like that… can’t still see clear about all these errors…
Finally, it seems I solved all my problems (I’m still testing though…)
I solved the 502 proxy error by installing a newer version of eJabberd. We were using the version 2.0.1 for now (yeah that’s quite old, but you know how it is in an project, once something works, we have no time to make these kind of updates…)
So I tried the version 2.0.5, the last stable version of the 2.0 branch and I can’t make the issue happen again. Because the only BOSH error fixed is in the version 2.0.3 and concerns the order of packets, maybe there was something like this and it was translated in my app by a 502 error ? … Strange…
And for the 404 error I received, I noticed that I could make it happen each time I was not touching my app about 30 seconds. Then if I was changing my presence or whatever to send a message to eJabberd, I was getting a 404 from URLLoader (with no XML data retrieved).
I solved this issue by removing the patch you posted a few days ago where the pollServer method call was removed from XMPPBOSHConnection class. It may cause any issues in a web-based application but I think that AIR is not behaving like any web browsers and needs to poll constantly the server. And no 404 error / disconnection occured since I did this.
That is strange. The patch did not remove the polling, but only deferred it until the connection knows there is no actual data to send. I am able to reproduce this bug, thanks for pointing it out! Will work on a fix now and post soon.