Server Disconnects Users Randomly

Openfire Openfire Support
1

Removed.

2

Any luck? we’re seeing the exact same issue.

  • pidgin/adium users dropping then instantly reconnecting.

  • "RoutingTableImpl: Failed to route packet to JID: " a number of times

with “tune” updates

<event xmlns=“http://jabber.org/protocol/pubsub#event”>

&lt;items node="http://jabber.org/protocol/tune"&gt;

  &lt;item id="c7S1yj8JlTr9nJ1" node="http://jabber.org/protocol/tune"&gt;

    &lt;tune xmlns="http://jabber.org/protocol/tune"/&gt;

etc.

3

Nope :(. I have been playing around with a few differnt

servers (PowerEdge 2850 Server 03, PowerEdge 2850 Ubuntu, and PowerEdge 2850

CentOS 5.1) and still no luck. I first thought it was a database problem but it

appears its more than that. I am about to call it quits with Openfire and try

another open source server L.

4

Urgh

We’ve had openfire running very stably until the last upgrade to 3.5.1. We had a similar issue for ~8 hours one day and then smooth sailing for a month or so until today.

I’m about to do a fun ‘midday upgrade’ to 3.5.2 to see if it addresses anything.

5

Really, all this started happening after we upgraded too.

Maybe I’ll try downgrading. Just about everyone that uses pidgin on windows

machines HATE me ;).

6

Please try setting the System Property xmpp.client.idle to -1 and see what happens.

daryl

7

It has been set that way for a few weeks. I also just did the 3.5.2 upgrade and we’re still seeing the same behavior.

8

I wonder if this is related to the release of a new Adium version. We have been running stable on 3.5.2 for about 1.5 weeks and suddenly this morning the server started disconnecting almost everyone intermittently. We tried everything we could think of, including completely reinstalling openfire to no avail.

9

rchady wrote:

I wonder if this is related to the release of a new Adium version. We have been running stable on 3.5.2 for about 1.5 weeks and suddenly this morning the server started disconnecting almost everyone intermittently. We tried everything we could think of, including completely reinstalling openfire to no avail.

Apparently definitely related! And it looks like it’s already been fixed in their trac:

“Any server or client which requests jabber:iq:version from us produces a denial-of-service because I screwed up with the new code which lets libpurple know about Adium’s version. Argh. Thanks for your help.”

Fingers crossed there will be a new release asap. For now the recommendation is to roll back to 1.2.5 (download link: http://adiumx.cachefly.net/Adium_1.2.5.dmg )

Ref:

http://trac.adiumx.com/ticket/10324

http://adiumx.com/blog/2008/07/adium-126-the-client-version-you-are-using-is-too -old-not/#comments

http://blog.lib.umn.edu/oit/apple/2008/07/adium_update_causes_instabilit.html

10

That would definitely do it. What’s the solution for pidgin? I did notice they came out with a newer

version of libpurple 2.4.3 but nothing was mentioned about this problem.

“Fix a crash when the given jabber id is invalid.

Fix a memleak when handling jabber xforms.”

Also, why does it work for some people, but then give the boot to others?

11

For me, the solution for pidgin is xmpp.client.idle = -1

I hope this workaround won’t be necessary with Openfire 3.6.0, as it will support XMPP-Ping, which Pidgin blindly sends it seems.

daryl

12

That is not showing up in the Web Management Console, should i go into the db and mannualy change it?

13

Just add it on the bottom of the page on the web console by filling out the form. Note, the setting will take effect for new client connections.

daryl

14

The Adium people are saying that the cause for the DoS attack from the client side was related to how they were interacting with pidgin, so evidently it’s an Adium-specific issue.

As for why it’s only affecting certain people – had everyone upgraded to the latest client? On our network even people with older adium were getting affected and there was some general slowness (took forever to join a MUC) but I suspect that is more related to the traffic level generated. A handful of people who’ve upgraded have left for the night while still leaving Adium running and (though I’m about to yank their network cables have been generating a ton of traffic spikes the last hour.

Finally, as for xmpp.client.idle = -1, this definitely addresed a confusingly similar looking issue we were having where a chunk of adium/pidgin users were getting disconnected ~hourly, but that was explained by the fact that pidgin/adium (at the time, at least) were not sending heartbeat packets.

15

How small can these windows get ;). Thanks alot for your help, i just added that value and can hopefully sleep a little better knowing it should work. I am not going to choose a best answer until it gets fixed.

16

In regards to the image, that’s EXCATLY what i was

seeing. As for clients, there will be a mandatory update tomorrow

17

let’s see how tiny

ok, ok, last note for the evening.

Honestly, the “best answer” is both (xmpp idle and roll back adium) imo.

xmpp.client.idle = -1 is known to workaround the issue with adium/pidgin not sending heartbeats. Unless you have untrusted users/people who shouldn’t be idling indefinitely, it should be set.

rolling back adium should also be a given w/ the known jabber issue. It looks like they’re moving quickly with a fix:

http://adiumx.com/blog/2008/07/adium-126-xmpp-jabber-failures/#comments

I was hoping that they’d be able to just pop out a bumpable update, but I suppose there is procedure and all.

Anyway, cheers to rchady for pointing out that there was an Adium update. I’d have been fumbling around quite a bit longer otherwise. Packets/min is down to ~700 from a high of 19k.

Good luck with your servers tomorrow, guys.

18

Looks like everything is working golden, thanks for all your help.