After upgrade, many users complain me about disconnect when type long message in russian. Clients soft used: Qip-infium. Kopete clients disconnected time to time whithout any cause. In server setup i set “Do not disconnect clients that are idle.”, but this is not help.
In 3.6.4 all clients work fine whitout disconnect.
Is anyone else experiencing issues like these?
Andrey, can you provide us with XML logs taken on the computer that is running the clients that are disconnected. I wonder what the protocol flow is.
Is anyone else experiencing issues like these?
confirm that, there is a problem with sending text in russian. Client Miranda.
I have the same problem
I Send logs to e-mail.
Hello all,
Thanks for responding. I would like some more information:
Same problem to me, when upgrade to 3.7.0, if user type a little long Chinese chractor, user will be offline.
So many user report this, I no ieda, so downgrade to 3.6.4
but the new plugin not work in 3.6.4, such as many useful import export user data plugin
I no backup those plugin, we have 700+ user accout in openfile.
Server OS is: Windows 2003 server.
You can find older version of userImportExport plugin here http://community.igniterealtime.org/message/209964#209964 Also i can upload any other plugin compatible with 3.6.4 version.
thank you wroot !
http://download.huihoo.com/openfire/plugins/
I found this link, I use the old plugin now.
i confirm this issue…
after updating to 3.7.0 from 3.6.4 our users faced with random disconnects when sending messages (messages sends in russian language). clients - miranda and qip infium.
some logs:
org.apache.mina.filter.codec.ProtocolDecoderException: java.nio.charset.MalformedInputException: Input length = 1 (Hexdump: 3C 6D 65 73 73 61 67 65 20 74 79 70 65 3D 27 63 68 61 74 27 20 74 6F 3D 27 64 73 40 6A 61 62 62 65 72 2D 6E 65 77 2E 70 6F 6C 69 63 6F 6D 62 61 6E 6B 2E 70 63 62 2F 51 49 50 27 20 69 64 3D 27 6D 69 72 5F 32 37 27 3E 3C 62 6F 64 79 3E 20 61 64 6D 31 35 20 28 31 31 3A 31 38 3A 31 38 20 31 32 2F 30 33 2F 32 30 31 31 29 0A 20 61 64 6D 31 35 20 28 31 31 3A 30 37 3A 35 33 20 31 32 2F 30 33 2F 32 30 31 31 29 0A D1 83 D0 B6 D0 B0 D1 81 2E 2E 2E 0A 20 61 64 6D 31 35 20 28 31 31 3A 30 38 3A 32 32 20 31 32 2F 30 33 2F 32 30 31 31 29 0A D0 BE 20 D1 87 D0 B5 D0 BC 20 D1 82 D1 8B 3F 20 D0 BF D1 80 D0 BE 20 D1 85 D0 BE D0 B4 20 D0 BC D1 8B D1 81 D0 BB D0 B8 2E 2E 2E 0A 20 61 64 6D 31 35 20 28 31 31 3A 31 30 3A 32 31 20 31 32 2F 30 33 2F 32 30 31 31 29 0A D1 8F 20 D0 BF D0)
at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecF ilter.java:170)
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:662)
Caused by: java.nio.charset.MalformedInputException: Input length = 1
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:183)
at org.jivesoftware.openfire.nio.XMPPDecoder.doDecode(XMPPDecoder.java:41)
at org.apache.mina.filter.codec.CumulativeProtocolDecoder.decode(CumulativeProtoco lDecoder.java:133)
at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecF ilter.java:163)
… 9 more
2011.03.12 11:33:22 Closing session due to exception: (SOCKET, R: /172.16.1.22:1903, L: /172.16.1.87:5222, S: 0.0.0.0/0.0.0.0:5222)
org.apache.mina.filter.codec.ProtocolDecoderException: java.nio.charset.MalformedInputException: Input length = 1 (Hexdump: BE D0 B7 D0 B0 D0 B2 D1 87 D0 B5 D1 80 D0 B0 20 D0 BA 20 D0 BD D0 B0 D1 88 D0 B8 D0 BC 20 D0 B1 D0 B0 D1 80 D1 8B D1 88 D0 BD D1 8F D0 BC 20 D0 B7 D0 B0 D1 85 D0 BE D0 B4 D0 B8 D0 BB D0 B0 2E 20 D0 93 D0 BE D0 B2 D0 BE D1 80 D0 B8 D0 BB D0 B8 20 D0 BF D1 80 D0 BE 20 D1 80 D0 B0 D0 B7 D0 BD D0 BE D0 B5 2E 20 D0 98 20 D0 A1 D0 B2 D0 B5 D1 82 D0 BA D0 B0 20 D1 80 D0 B0 D1 81 D1 81 D0 BA D0 B0 D0 B7 D0 B0 D0 BB D0 B0 2C 20 D1 87 D1 82 D0 BE 20 D0 A3 20 D0 94 D0 B8 D0 BC D1 8B 20 D0 B1 D0 B0 D0 B1 D1 83 D1 88 D0 BA D0 B0 20 D0 B6 D0 B8 D0 B2 D1 8F 20 D0 B2 20 37 30 2D D1 85 20 D0 B2 D1 81 D0 B5 D0 B3 D0 B4 D0 B0 20 D0 B8 D0 BC D0 B5 D0 BB D0 B0 20 D0 BC D0 B5 D1 88 D0 BE D1 87 D0 B5 D0 BA 20 D1 81 D1 83 D1 85 D0 B0 D1 80 D0 B5 D0 B9 2E 2E 2E 2E 20 D0 93 D0 BE D0 B2 D0 BE D1 80 D0 B8 D0 BB D0 B0 20 D0 A1 D0 B2 D0 B5 D1 82 D0 BA D0 B0 2C 20 D1 87 D1 82 D0 BE 20 D0 BE D0 BD D0 B0 20 D0 B3 D0 BE D0 BB D0 BE D0 B4 20 D0 BF D0 B5 D1 80 D0 B5 D0 B6 D0 B8 D0 BB D0 B0 2E 20 D0 92 D0 BE D1 82 20 D0 B8 20 D0 B2 D1 81 D0 BF D0 BE D0 BC D0 BD D0 B8 D0 BB D0 B0 20 D0 BE D0 B1 20 D1 8D D1 82 D0 BE D0 BC 2C 20 D0 BA D0 BE D0 B3 D0 B4 D0 B0 20 D0 BF D1 80 D0 BE 20 D1 8F D0 BF D0 BE D0 BD D1 86 D0 B5 D0 B2 20 D1 82 D0 B5 D0 B1 D0 B5 20 D0 BF D0 B8 D1 81 D0 B0 D0 BB D0 B0 2E 3C 2F 62 6F 64 79 3E 3C 61 63 74 69 76 65 20 78 6D 6C 6E 73 3D 27 68 74 74 70 3A 2F 2F 6A 61 62 62 65 72 2E 6F 72 67 2F 70 72 6F 74 6F 63 6F 6C 2F 63 68 61 74 73 74 61 74 65 73 27 2F 3E 3C 78 20 78 6D 6C 6E 73 3D 27 6A 61 62 62 65 72 3A 78 3A 65 76 65 6E 74 27 3E)
at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecF ilter.java:170)
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:662)
Caused by: java.nio.charset.MalformedInputException: Input length = 1
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:183)
at org.jivesoftware.openfire.nio.XMPPDecoder.doDecode(XMPPDecoder.java:41)
at org.apache.mina.filter.codec.CumulativeProtocolDecoder.decode(CumulativeProtoco lDecoder.java:133)
at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecF ilter.java:163)
after studying the issue, I came to the conclusion that disconnects occurs when user sends a long message (the message does not reach the addressee). short run without problems
i revert to 3.6.4 - the problem disappeared
Should the length check on line 180 of XMLLightweightParser.java be checking the length of the parameter and not the global buffer?
We are having the same problem in our office - I just upgraded to v3.7.0 this past Sunday (March 13th), and there has been a steadily increasing number of “disconnect issue” reports since that time.
In our case we are using regular US English (no special characters) and the condition which triggers the disconnect is sending a large chunk of SQL queries or errors (the person who sends the SQL message in our case disconnects the recipient, who doesn’t get the message).
I am unable to find any meaningful clues in the OpenFire logs, but if a bugfix release is not scheduled for this problem soon - I see no other choice but to rollback to 3.6.4 (which was ROCK SOLID for almost a year). Our development team is half Data Engineers, half Developers - so the need to send large SQL queries to one another over our internal chat system (OpenFire) is not going to be disappearing any time soon.
I would like to cast my vote that this issue be treated as a high and addressed as soon as possible. (!!)
As an aside to everyone else who has already rolled back to 3.6.4; any idea how to supress the automated “upgrade available” messages that are sent to Jabber client’s of OpenFire administrators??
Thanks,
-David.
I have filed this as OF-442, though i can’t reproduce this on my side. Tried to send large messages, both Exodus and recent Spark build are ok.
I suppose that I should have also included some client information (whoops, my bad!):
Our office is almost 100% MAC. We run Adium (1.4.1) on OSX 10.6.6 (Intel).
Even the few QA testers who have Windows boxes use PSI as their jabber client, but no one in our office uses Exodus or Spark as a jabber client.
Perhaps this has to do with a subtely of Adium’s Jabber implementation?? (my $0.02)
To the best of my knowledge this issue has only been reported by Adium users on OSX, no PSI users have reported this kind of trouble yet to the best of my knowledge.
Thank you for creating a bug report for this issue so quickly, I appreciate it!!
I hope this extra info helps,
-David.
So far reporters mention Qip Infium, Miranda. Would be helpful if everyone would report what clients do they use. But it looks like not Mac only issue.
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.