Hello,
We're having a handful of users who are reporting random disconnects from our Openfire server. The common theme seems to be that they're all using pidgin. This was happening in both Openfire 3.5.2 and the newest version of Openfire 3.6.0. Here's the stack trace I see in the logs when someone gets disconnected:
java.lang.IllegalArgumentException: IQ must be of type 'set' or 'get'. Original IQ: <iq type="result" id="xxx-xxx" to="servername.xxx.com" from="user@server.xxx.com/Home"><query xmlns="http://jabber.org/protocol/disco#info"><identity category="client" type="pc" name="pidgin"/><feature var="jabber:iq:last"/><feature var="jabber:iq:oob"/><feature var="jabber:iq:time"/><feature var="xmpp:urn:time"/><feature var="jabber:iq:version"/><feature var="jabber:x:conference"/><feature var="http://jabber.org/protocol/bytestreams"/><feature var="http://jabber.org/protocol/disco#info"/><feature var="http://jabber.org/protocol/disco#items"/><feature var="http://jabber.org/protocol/muc"/><feature var="http://jabber.org/protocol/muc#user"/><feature var="http://jabber.org/protocol/si"/><feature var="http://jabber.org/protocol/si/profile/file-transfer"/><feature var="http://jabber.org/protocol/xhtml-im"/><feature var="urn:xmpp:ping"/><feature var="http://www.xmpp.org/extensions/xep-0199.html#ns"/><feature var="http://jabber.org/protocol/mood"/><feature var="http://jabber.org/protocol/mood+notify"/><feature var="http://jabber.org/protocol/nick"/><feature var="http://jabber.org/protocol/nick+notify"/><feature var="http://jabber.org/protocol/tune"/><feature var="http://jabber.org/protocol/tune+notify"/><feature var="http://www.xmpp.org/extensions/xep-0084.html#ns-metadata"/><feature var="http://www.xmpp.org/extensions/xep-0084.html#ns-data"/><feature var="http://www.xmpp.org/extensions/xep-0084.html#ns-metadata+notify"/></query></iq>
at org.xmpp.packet.IQ.createResultIQ(IQ.java:355)
at org.jivesoftware.openfire.IQRouter.route(IQRouter.java:104)
at org.jivesoftware.openfire.spi.PacketRouterImpl.route(PacketRouterImpl.java:68)
at org.jivesoftware.openfire.net.StanzaHandler.processIQ(StanzaHandler.java:311)
at org.jivesoftware.openfire.net.ClientStanzaHandler.processIQ(ClientStanzaHandler .java:79)
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:276)
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:175)
at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandl er.java:133)
at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived (AbstractIoFilterChain.java:570)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)
at org.apache.mina.common.IoFilterAdapter.messageReceived(IoFilterAdapter.java:80)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)
at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimplePr otocolDecoderOutput.java:58)
at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecF ilter.java:185)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)
at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java :239)
at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(Execut orFilter.java:283)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
at java.lang.Thread.run(Unknown Source)
Any ideas?
Hi,
I routinely see that error with my pidgin users, but I don't believe it produces a disconnection. Are you sure about that association?
Wanna try setting xmpp.client.idle to -1 on the Server settings of the admin console and see if that helps your disconnects?
daryl
Hi Daryl,
You're right. This error does not appear to be producing the disconnection. I made this change, but the disconnects are still happening. I've been working closely with a user trying to figure out the source of the disconnects. He got disconnected, I went to the logs, and saw a couple of these errors, but not for the user in question. He got dropped at 2008.08.28 16:57:41, which is the same in the logs that these errrors appeared.
Again, this only happens for pidgin, and it also seems like all of the users are getting disconnected at the same time...
Compression is turned off and xmpp.client.idle is -1... we do have TLS enabled... that's the only other thing I can think of?
Is this an Openfire issue or something with our network? Any ideas?
Hi,
The server config setting will only take effect for *new* connections. Are you still seeing disconnects after clients newly connect after the config setting change?
Otherwise, please consider starting one of your pidgin clients with the -d flag and see if you can trace what is happening.
daryl
Hi Daryl,
Your suggestions, along with the new release of Pidgin, seem to have substantially improved this issue for us. However, we're still having users report disconnects every once in a while. Sometimes there aren't any errors or warnings or anything when someone drops. Is there some kind of interoperability issue between Pidgin and Openfire?
Hi,
There are some issues that can cause trouble with Pidgin and Openfire. In fact, you will find my name a lot in the Pidgin bug trac referencing some of these problems. Invariably, the Pidgin devels point their finger at Openfire for causing the troubles and the openfire devels are more keen on supporting issues with spark[web]. I don't believe the pidgin devels test against openfire for various reasons, so what's my point...
If you have troubles, try to open up the XML debug console on Pidgin and see if you can catch the disconnect in action. Putting openfire into debug mode may help as well...
I have an install base of 2900 users, with most of them running Pidgin, but for the most part, things work just great! If they continue to look bad for you, check out other clients, like Spark (hi winsrev
). Thankfully, there are many quality options out there.
HTH,
daryl
Daryl,
I had a user send me one of his log files. Here are some of the errors in the logs:
1. jabber: XML parser error for JabberStream 01DB3DF8: Domain 1, code 5, level 3: Extra content at the end of the document
2. jabber: Recv (ssl)(316): <iq type="error" id="purple109f21d" from="xxxxxxx@conference.chat.xxx.com" to="xxxx@chat.xxx.com/Home"><query xmlns="http://jabber.org/protocol/disco#info" node="http://jabber.org/protocol/muc#traffic"/><error code="404" type="cancel"><item-not-found xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></iq>
3. jabber: XML parser error for JabberStream 01DB4048: Domain 1, code 100, level 1: xmlns: URI vcard-temp is not absolute
The 1st error seems to be causing pidgin to crash. I don't have enough data about the 2nd error, but it seems to be related to connection issues with our chat rooms. The 3rd error seems harmless, everything still runs fine even though pidgin spits out those errors.
Any ideas?
amullen wrote:
Hi Daryl,
Your suggestions, along with the new release of Pidgin
You mean, you already tried 2.5.1? Cause i saw in the changelog:
* Avoid disconnecting from XMPP servers on parse errors that are non-fatal.
Yes, apparently this is still happening under 2.5.1. I've asked the users who are having these issues to start debugging their Pidgin sessions and send me the logs when they crash, but I've yet to receieve one ![]()
Same issue here with Pidgin, random disconnects after upgrading the version of Pidgin to 2.5.2 from 2.3.1. The old version works fine but the new version disconnects. It looks like the main change in Pidgin was the way it handles SSL certificates. Any ideas?