hi *,
from version 2.4 up of wildfire we are facing an error with messages sent from clients that build the new line character with the key combination shift + enter/return, this is the case for example of gaim (windows and linux), adiumx (mac), they all use the libgaim library.
multi line messages sent from libgaim clients arrive incomplete. from the second line down only the last word of line arrives. they have no problem receiving multi line messages from other clients and they have no problem sending multi line messages using servers like jabber.org.
for example if you send:
"this is a
multi line message"
the other end receives:
"this is a
message"
a different problem happens with apple ichat. apple ichat builds the new line character with the same key combination as the libgaim clients i mentioned, but what happens is that the new line character is not obeyed.
for example if you send:
"this is a
multi line message"
the other end receives:
“this is amulti line message”
this problem is new to wildfire, we never faced this problem with jive_messengerd (old versions of wildfire) and the problem affects only messages sent from clients that build the new line character with the key combination shift + enter/return.
how to fix this problem? is this an error?
tia, md.
I did a little debugging via Psi (I wish more clients had an XML stream log) and found some information that might be useful to anyone looking into this.
It seems that clients like Psi (and Kopete) generally send plain-text messages and don’‘t have any trouble with multi-line messages. However, Gaim likes to send plain-text as well as XHTML. The plain-text messages sent by Gaim go through fine and since clients like Psi ignore the XHTML part, they display it fine as well. However, the XHTML message sent by Gaim doesn’'t get through the server correctly, it exhibits the behavior described above. Thus any client that will display the XHTML version of the message in preference to the plain-text one will show a cut-up message.
What I haven’‘t managed to figure out is whether the server is mangling the message, or whether it’‘s Gaim. Since our server setup only allows SSL connections I haven’‘t been able to trace the stream. My guess is that it’'s the server only because this worked on Messenger 2.1 (we just upgraded to Wildfire 2.4 this last Friday).
Hey guys,
You have hit a known problem that was introduced since c2s hearbeats were added to Wildfire. The jira issue for this problem is JM-500. In that bug report you may find a brief explanation of the reason for the problem. Fixing this problem is already in our TODO list but if you want to raise its priority then you can vote for it.
Thanks,
– Gato
To us it is unacceptable for our IM system to arbitrarily drop data. And since we really[/b] didn’‘t want to go back to version 2.1 (the last usable version for us, for other reasons) I’'ve found the cause of this and made a patch. It might break the heartbeat stuff they added recently, but we had to turn that off anyway since it also[/i] breaks Gaim.
diff -ur wildfire_src.orig/src/java/org/jivesoftware/wildfire/net/MXParser.java wildfire_src/src/java/org/jivesoftware/wildfire/net/MXParser.java
— wildfire_src.orig/src/java/org/jivesoftware/wildfire/net/MXParser.java 2006 -01-12 19:03:39.000000000 -0800
+++ wildfire_src/src/java/org/jivesoftware/wildfire/net/MXParser.java 2006-01-1 8 10:57:00.000000000 -0800
@@ -257,11 +257,13 @@
do {
// check that ]]> does not show in
if (eventType == XmlPullParser.END_TAG && (ch == ‘’ ‘’ || ch == ‘’\n’’)) {
// ** ADDED CODE (INCLUDING IF STATEMENT)
return IGNORABLE_WHITESPACE;
}
if(seenBracket) {
seenBracketBracket = true;
} else {
/code
This patch will remove the heartbeats feature and it will parse all data. Remember to disable the hearbeat by setting the system property to -1 so the server doesn’'t drop connections.
Regards,
– Gato