Success! I have isolated the conditions needed to reproduce this issue! (in our environment anyways)
Sending the message: ORA-00904: “ALERT_USER_PREF_ID”: invalid identifier
From one client to another causes the problem, BUT ONLY IF the client sending the message is running Adium v1.3.10!
While sending the same message body between Adium v1.4.1 -> v1.4.1 or Adium v1.4.1 -> Adium v1.3.10 is not affected!
I hope this helps.
-David.
Ok. Though i don’t know if Guus has access to Mac machine to do testing. Personally i don’t have a Mac and i wasn’t able to run recent Mac OS X versions in VirtualBox.
In the interim I have broadcast a message to my users that they should upgrade Adium to v1.4.1 immediately - which I find to be a highly preferable work-around to rolling OpenFire back to v3.6.4.
As i said Guus has no Mac machine to test, only some image at our building system Bamboo, but it seems to be faulty. We need to ask Jive guys hosting this site to fix it. So far i can suggest to rollback to 3.6.4 as it seems this issue will not be fixed anytime soon.
Btw, you can disable messages about server update Server > Server Settings > Manage Updates
A similar problem.
Clients disconnect after upgrade to openfire 3.7.0 on WinXP and Debian too.
A similar problem. Languadge Russian
Clients disconnect after upgrade to openfire 3.7.0 on Win2003serv and CentOS too.
Where can I download 3.6.4 for linux? Please
Just change version number in the download link, like http://www.igniterealtime.org/downloads/download-landing.jsp?file=openfire/openf ire-3.6.4-1.i386.rpm
Hi Guys. Roger that as well. Openfire 3.7.0. Windows Server 2003, client QIP Infium last buld 9044 (also tried with last QIP 2010 build). When U sending long msg, its suddenly disconnect U from the server.
Want to roll back to 3.6.4, but Monitoring Plugin seems doesnt work on it, could some one send me the old version of monitoring plugin compatible with 3.6.4, Ill be very appreciated.
I know that with its own client SPARK everything is ok, but we do prefer QIP Infium instead of SPARK, and I really hope, that someone will find a FIX for this problem, since it wasnt in version 3.6.4!
Thx a lot Sincerely Nail.
This problem may be caused by org.jivesoftware.openfire.nio.XMLLightweightParser
at line 116 for version 11844
encoder = Charset.forName(charset).newDecoder()
.onMalformedInput(CodingErrorAction.REPORT)
.onUnmappableCharacter(CodingErrorAction.REPORT);
ant for version 11388
encoder = Charset.forName(charset);
this means that cs.newDecoder() .onMalformedInput(CodingErrorAction.REPLACE) .onUnmappableCharacter(CodingErrorAction.REPLACE) .decode(bb);
It change from “CodingErrorAction.REPLACE” to “CodingErrorAction.REPORT”
So at line 183 :
encoder.decode(byteBuffer.buf());
It may throw exception for some situations, eg.MalformedInputException and UnmappableCharacterException.
And then it throw to outer and cause disconnect.
Before , “CodingErrorAction.REPLACE”, it don’t throw exception, and it’s OK, But now it’s error.
I modify it to try catch for a encoder.decode(byteBuffer.buf()); , show :
java.nio.charset.MalformedInputException: Input length = 2
at java.nio.charset.CoderResult.throwException(CoderResult.java:260)
at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:781)
at org.jivesoftware.openfire.nio.XMLLightweightParser.read(XMLLightweightParser.ja va:185)
at org.jivesoftware.openfire.nio.XMPPDecoder.doDecode(XMPPDecoder.java:32)
at org.apache.mina.filter.codec.CumulativeProtocolDecoder.decode(CumulativeProtoco lDecoder.java:133)
at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecF ilter.java:163)
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(ThreadPoolExecutor.java: 886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
at java.lang.Thread.run(Thread.java:619)
If I don’t catch it , it will disconnect.
I am able to reproduce the problem on Spark client (all versions, running on Windows, Ubuntu and MacOS).
The problem is not related only to the length of the message. In fact, the main responsible is CHARACTER ENCODING: I can create giant messages (10000 chars) that work perfectly, as long as they do not have extended unicode characters. On the other hand, if the message contains such symbols (you can choose what you want: æ, ß or any latin accented characters such as ã, é or à) then there exists a limit that will crash openfire.
What I suspect: memory allocation problem; extended unicode characters take 2 or more bytes to be stored, but openfire is using the actual lenght of the string to reserve memory; depending on the amount of these characters on a message, you’ll get the crash.
Hope it helps!
I have submited my patch to resolve the problem, see http://community.igniterealtime.org/message/213166#213166 .
wroot,
I think OF-442 is the same OF-458 , could you check it out?
Thank you!
I confirm the same problem. Server - Openfire 3.7.0 (Windows), clients - Pandion.
Clients randomly disconnect and then I have this in logs:
… java.nio.charset.MalformedInputException: Input length = 1 …
Messages are not long, but they are Unicode (Cyrillic). The problem’s nature is random:
client sends a message and server drops connection (message is not delivered)
client reconnects and sends exactly the same message - and server delivers message with no problem
This happens rather often (I have ~120 clients).
Please, somebody, patch Openfire (for Windows)! Some people here are not able to recompile latest Openfire with the patches we have here…
P.S. warn.log is attached.
warn.log.zip (1653 Bytes)
I confirm the issue (Linux + Openfire 3.7.0 + QIP Infium + Cyrillic long messages).
Is it safe to downgrade to 3.6.4 version without database changes (mysql)?
What is the right way to do it? Is it enough to stop 3.7.0, copy its conf file and start 3.6.4 with it?
I think it should work (3.6.4 with a databse already upgraded to 3.7.0). At least i think i’ve heard someobe doing such downgrade. You don’t have to copy anything, just start 3.6.4 (if you use internal database, then you’ll have to copy the database into 3.6.4 folder). Anyway, backup everything you can before doing this.
Upgrading to Openfire 3.7.1 Alpha solved the problem with disconnect on cyrillic messages for me. Read this: http://community.igniterealtime.org/message/213512
Download and replace this file: http://community.igniterealtime.org/servlet/JiveServlet/download/213405-11655/op enfire.jar
Try this before downgrade!
it works!
now hot testing…