Messages come in, but they don't go out

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.

Thanks in advance.

–df

Anyone? The powers that be are getting antsy, wanting to look at other IM solutions.

Thanks.

–df

Hi,

do you see any errors in the log files? Do you have still some free memory within Openfire?

LG

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.

Thanks again.

–df

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]

jive.audit-20080122-001.log:

<packet xmlns="http://www.jivesoftware.org" streamID="d28a03a5" status="auth" timestamp="Jan 21, 2008 11:56:11:454 PM">
  <message xmlns="" id="trill_99" to="danf@example.com" from="davidd@example.com/Trillian">
    <x xmlns="jabber:x:event">
      <composing></composing>
      <id>purple10e645eb</id>
    </x>
  </message>
</packet>
<packet xmlns="http://www.jivesoftware.org" streamID="655e4ed9" status="auth" timestamp="Jan 21, 2008 11:56:11:454 PM">
  <message xmlns="" id="trill_99" to="danf@example.com" from="davidd@example.com/Trillian">
    <x xmlns="jabber:x:event">
      <composing></composing>
      <id>purple10e645eb</id>
    </x>
  </message>
</packet>
<packet xmlns="http://www.jivesoftware.org" streamID="d28a03a5" status="auth" timestamp="Jan 21, 2008 11:56:11:764 PM">
  <message xmlns="" to="danf@example.com" id="trill_100" type="chat" from="davidd@example.com/Trillian">
    <body>sure</body>
    <html xmlns="http://jabber.org/protocol/xhtml-im">
      <body xmlns="http://www.w3.org/1999/xhtml">sure</body>
    </html>
    <x xmlns="jabber:x:event">
      <composing></composing>
      <offline></offline>
    </x>
  </message>
</packet>
<packet xmlns="http://www.jivesoftware.org" streamID="655e4ed9" status="auth" timestamp="Jan 21, 2008 11:56:11:764 PM">
  <message xmlns="" to="danf@example.com" id="trill_100" type="chat" from="davidd@example.com/Trillian">
    <body>sure</body>
    <html xmlns="http://jabber.org/protocol/xhtml-im">
      <body xmlns="http://www.w3.org/1999/xhtml">sure</body>
    </html>
    <x xmlns="jabber:x:event">
      <composing></composing>
      <offline></offline>
    </x>
  </message>
</packet>

Any other ideas?

Thanks.

–df

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.

Thanks again!

–df

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…

any ideas

I’m also occasionally seeing this behaviour on OpenFire 3.5.2.

Could anybody of the OpenFire devs chime in on who to diagnose this ? Logs don’t show anything useful.

This is a rather critical bug so any help/hints would be greatly appreciated…

Filip

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.

Hi,

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…

Thanks,

  • Filip

Btw, resending the exact same message works fine, so it can’t be the message formatting.

In my tests i have found it not to be the sender but the recipient. What is the client at the receiving end?

Client on the receiving end is Smack as well (so basic Smack -> OpenFire -> Smack).

Thanks,

  • Filip

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.

Thanks much,

Filip