Upgrade to 3.4.1 causing IllegalArgumentException and continuously disconnecting clients

Hi,

I ugpraded Openfire from 3.3.3 to 3.4.1 tonight, luckily a side-by-side installation. As soon as I’d upgraded … all the automated clients start going mental, continually disconnecting and reconnecting to the server.

Upon every single disconnect, I get the following in the warn.log:

2007.11.12 18:50:30 Invalid presence show for -<presence id=“id_690147”><show>online</show><status>a status message string</status></presence>

java.lang.IllegalArgumentException: No enum const class org.xmpp.packet.Presence$Show.online

at java.lang.Enum.valueOf(Enum.java:192)

at org.xmpp.packet.Presence$Show.valueOf(Presence.java:377)

at org.xmpp.packet.Presence.getShow(Presence.java:136)

at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:230)

at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:167)

at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandl er.java:132)

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.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimplePr otocolDecoderOutput.java:58)

at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecF ilter.java:162)

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 :240)

at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(Execut orFilter.java:284)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java: 650)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)

at java.lang.Thread.run(Thread.java:595)

These are automated clients, which haven’t changed for many many months, and have been working seamlessly with many versions of Wildfire/Openfire.

Has something changed in the implementation which means it’s more strictly implementing a JEP with regard to the status <show> field?

The client I am using is written using Muse. I have a second version using Smack, but was having some other issues with that (unrelated).

I always check the release notes, and didn’t see anything which caused me to believe there would be a problem with the upgrade, any help would be much appreciated.

Mark

Hi Mark,

according to http://tools.ietf.org/html/rfc3921#section-2.2.2.1 your client violates the protocol. I could wonder why the checks are more strict now within Openfire but I really prefer strict checking over a very lazy one which is used within HTML/XHTML and most browsers. I guess “show” was simply removed from the enum list.

If XMPP server vendors do not check the schema of all xmpp packets strictly the users may end up with incompatible clients. So I did suggest to add a schema validator for everything. Currently the invalid vCards which are created by Spark are accepted by Openfire, clients which try to render them according to the xml schema simply fail.

LG

Thanks for the prompt response! I will check the client, can’t remember if it’s MY code or the external API’s which is using “show”. I’ll have a google for the list supported values in the enumeration, if you know of one, by all means feel free to share it with me

Thanks again.

Mark

Hi Mark,

you should click on the link I did post. It’s the RFC and thus the best source and also the right section within it.

LG

I have resolved the issue by putting a workaround in the code, as the problem appears to be that Muse’s API allows you to use a constant on the interface for “Online” show status.

I will contact the muse team, if possible regarding this.

Whether openfire should be booting the user off the server simply for specifiying an invalid status value is questionable in my opinion, I could understand simply ignoring the presence packet, or like previous versions, handling the XML value as invalid and assuming it "available/online, but disconnecting it seems somewhat OTT.

Anyone have thoughts about this?

Hey Mark,

Sending a presence packet with an invalid show value like this one:

<presence><c node="http://exodus.jabberstudio.org/caps" ver="0.9.1.0" xmlns="http://jabber.org/protocol/caps"></c><show>online</show><priority>1</priority></presence>

just logs a warning but does not disconnect you from the server. I just tried in my local server and also against jivesoftware.com and they worked fine. May be some plugin is causing the disconnection? You can try sending an invalid show value in your presence when connected to jivesoftware.com to test it.

Regards,

– Gato