Openfire 3.4.3 occasionally becomes a roach motel: messages come in, but they don’t go out. Every now and then, someone will send a message, and I can see it in the message archive (using the Open Archive plugin), but the message isn’t sent to the recipient. The same thing happened in 3.4.2.
Any ideas on how I can track this issue down? Very often, disconnecting and re-connecting the client fixes it, although any previous messages are lost.
it2000, thanks for the tip. I haven’t noticed any error messages in the log files, but I’ll keep an eye on the memory. Is there any way to query the memory usage from the command line, so I can setup a cron job to check it? I see it in the main server page in the HTTP interface.
The memory usage stays low, even during the “roach motel” times. For example:
17.73 MB of 487.31 MB (3.6%) used
Here are the log entries from a message that never made it to my client, even though they are on the server. I replaced our domain with example.com. I am danf, the sender was davidd. I reformatted the XML output to make it legible.
stdoutt.log:
Indexed ArchivedMessage[id=509324,time=Mon Jan 21 23:56:11 CST 2008,direction=from]
Indexed ArchivedMessage[id=509325,time=Mon Jan 21 23:56:11 CST 2008,direction=to]
Anyone? I’ve run out of options for getting Openfire to work right, and in fact a completely separate installation of Openfire is now exhibiting this same behavior. I’ve started setting up ejabberd, which makes me appreciate the amazingly rich web interface for administering Openfire. I really, really want to keep using Openfire, but with messages disappearing like this, I simply can’t.
just wondering if you ever got anywhere with this. we are seeing this behaviour now. Its been going on a while, just not reported! useful
installed iball to log messges and sure enough they go in, and some dont go out again as you described, we have upagreded to the lastest version yet still it remains broke. we run pandion/spark and psi across linux/xp and osx and all disaply this problem, which would point to a server fault…
The only similar issue I have seen with regards to this are the spark on the receiving end does not display the message. The server actually delivers it to the client the client just never displays it. If the client has history running it will show in the history on the next launch of spark. This may not be the same issue for you.
Thanks for the reply. I’m not using Spark but the Smack library to send custom messages. Most of them go through, but some messages simply don’t arrive on the other side (I have a packetListener on the other side and nothing comes in).
I’m stumped by this… I would expect to find a trace of the messages at least somewhere…
So… I think I have a pretty good hint on what’s going on now. As suggested, the problem seems to be the Smack library, not OpenFire.
I send automated messages, so it’s a basic (login; send message; disconnect) cycle. If I immediately disconnect some messages are dropped (I found this out using a remote server - it seems the connection speed has something to do with it); if I put a simple Thread.sleep(2000) after sending the message, but before the disconnect(), things work.
I would say that’s a bug in the Smack library: when disconnecting it should flush all messages (or maybe there’s a separate flush() call that I haven’t seen?).
Any of the Smack developers have any hints ? Or can confirm this behaviour ? I’d love to get rid of the arbitrary delay in the code.