I have two installations of openfire, one locally and one on a remote server. Locally I have no problems but with the remote installation, I find that frequently when I login using my custom flash client (which automatically joins the user to two chat rooms), openfire never sends the room join and subsequent room roster messages (it seems to send them the first time a given user logs in but then if I logout and log back in, the message does not get sent). Other logged in users get a room roster update event every time. I am tracing out all incoming data from the socket in my flash client so am fairly certain the message is never getting sent from Openfire. Additionally, I have a script (for testing purposes) which polls an rss feed and then pushes any new entries found to the appropriate users as private messages. More often than not only some of the private messages are actually sent to the recipient’s client by openfire. For instance, if an rss feed is polled and has 8 new messages and I thus create and send 8 private messages, Openfire may deliver all 8 messages as requested or it may deliver just 4 or even 2.
Has anyone else had strange issues like this with messages apparently not being generated / delivered by Openfire? I have turned on debugging and have watched the logs but to no avail. This is especially frustrating given that my local deployment of Openfire does not exhibit any of these problems. Any suggestions or thoughts would be appreciated.
Hey Nathan,
Could you use the attached xml debugger plugin to monitor traffic to/from the server? Also do you see any exception on the log files?
Thanks,
– Gato
btw, which sever version are you using? And have you tried using another XMPP client to see if the problem still happens?
Regards,
– Gato
Am curently running openfire 3.4.4 - have not tried another XMPP client yet.
I am installing the xmldebugger now so will post once I have some additional information.
More information, thanks to the xmldebug jar provided above -
-
openfire appears to be sending all messages but it is concatenating them together
-
when tracing the actual incoming data from the xiff library XMPPSocketConnection, it appears the data received from Openfire comes in chunks with some maximum length and the breaks don’t always occur such that valid xml stanzas are sent, as a result the XIFF library is choking on invalid xml and any messages sent in that chunk are lost. Example from my app, one xml string ends mid-attribute “s.com/messa” and the next xml string begins where that one left off, “ges/…”
So, the question remains, why does this work for me locally but not on the server installation? Is there a setting that tells openfire to send x number of bytes at a time? Is there an XIFF patch that checks for incomplete xml and waits for the remainder of that xml stanza before parsing?
Thanks for the help so far - any additional thoughts?
Are you using XMPPConnection or XMPPSocketConnection in XIFF? XMPPSocketConnection seems to have some issues.
I am using XMPPSocketConnection - I just found a few other posts on the XIFF forums that suggest the binary socket may be the problem. It appears that the socket ProgressEvent fires when a given amount of data has been read but doesn’t really care if the bytesAvailable form a valid xml stanza (or set of stanzas) or not. So for concatenated messages, often the event fires when only part of a valid xml stanze has finished loading.
Not sure why the XMPPConnection (non binary socket) works better but I guess if it does the trick, I’m not going to argue it at this point.
Basically the same conclusion I came to. It’d be nice to fix at some point, but isn’t a pressing priority. 
Final resolution - at least for now.
The flash binary socket connection doesn’t have any concept of “valid xml” and as a result, it sends data progress events at intervals based on some other criteria rather than having received a completely valid xml document, stanza or set of stanzas. There are two possible solutions that I can think of. 1) use the XMLSocket (XMPPConnector rather than XMPPSocketConnector in the XIFF library) or 2) modify either the extended Socket class or the XMPPSocketConnector bSocketReceiveData function in the XIFF library to validate the incoming data string as containing complete xml stanza(s) before trying to parse and if any stanza is not complete, wait to parse that until the next data progress event is caught. I spent a few hours doing this today and it appears to work well - no more “dropped” packets, etc.
As per the last post, although I can understand the point being made, I disagree with the argument that this isn’t a critical issue with the XIFF XMPPSocketConnector class. In reality the class is simply not useable while this issue remains - note that I was not trying to send excessive amounts of data, this issue arose with very low-load use scenarios. Even if the temporary solution is to simply remove that class as an option or strongly and visibly recommend that users utilize XMPPConnector instead, some action should be taken - even in the opensource world it really isn’t acceptable to have blatantly broken code parading as functional code.
Forgot to mention in the last post - thank you to everyone who responded. The suggestions and especially the xmldebugger plugin were crucial in timely “resolution” of this issue.
Could you post a diff of your code?
Sure - I have attached the modified version of XMPPSocketConnection.as - there are too many changes to put just the difference up. This has been tested pretty thoroughly by a user base of ~1000 people and seems to be working effectively. Feel free to let me know if you find problems or more efficient ways to parse the incoming data.