powered by Jive Software

Spark visually shows that a message is not sent

So, an age old problem mentioned dozens of time in these forums starting from older versions (i think even prior 2.6).

A user types a message, hits Enter. The message is sent to the recepient, but the user still sees it in the input field and chat window doesn’t show it as sent. And the user usually can’t see incoming messages either. Often a user can close a chat window, open it again and then see message in the quick history. Usually a user needs to restart Spark to fix this.

So, as i have rolled out Spark to 200 users, i know get reports about such problem. So far about 10. Will try to investigate this and update this thread. One report was interesting. A user reported that she had that problem yesterday and tried to restart Spark couple of time with no success. But today everything is fine. So i suspect the history xmls and in particular the “current” one. This file stores recent messages and then they are moved to the whole history file. Maybe something gets bogged down in this file and after some time it fixes itself after it moves history to another file.

Yeah i had this problem too. The reason is because when Spark is updated, the profile of the user is not. And since the profile stores some libraries and stuff, it conflicts. Erasing the entire user profile in %appdata% and recreating it solves the problem.

Chat logs can be kept if needed.

I’m not so sure about that. We had this issue with only one version of Spark installed (no updates). And the only files that are not updated in the profile are plugins, which haven’t been changed for a long time.

Well don’t ask me why it happens, since i don’t know much about java, and the log wasn’t very useful last time i had this problem.

But for the users that had this bug, erasing the profile did the trick.

When Spark fails to show that the message is sent, it is logging such error:

Rgp 12, 2013 2:07:11 PM org.jivesoftware.spark.util.log.Log error

SEVERE: Error sending message


at java.util.Hashtable.put(Unknown Source)

at javax.swing.text.SimpleAttributeSet.addAttribute(Unknown Source)

at javax.swing.text.StyleConstants.setForeground(Unknown Source)

at org.jivesoftware.spark.ui.TranscriptWindow.insertMessage(TranscriptWindow.java: 191)

at org.jivesoftware.spark.ui.rooms.ChatRoomImpl.sendMessage(ChatRoomImpl.java:363)

at org.jivesoftware.spark.ui.rooms.ChatRoomImpl.sendMessage(ChatRoomImpl.java:346)

at org.jivesoftware.spark.ui.rooms.ChatRoomImpl.sendMessage(ChatRoomImpl.java:319)

at org.jivesoftware.spark.ui.ChatRoom.checkForEnter(ChatRoom.java:698)

at org.jivesoftware.spark.ui.ChatRoom.access$300(ChatRoom.java:90)

at org.jivesoftware.spark.ui.ChatRoom$3.keyPressed(ChatRoom.java:335)

at java.awt.AWTEventMulticaster.keyPressed(Unknown Source)

at java.awt.Component.processKeyEvent(Unknown Source)

at javax.swing.JComponent.processKeyEvent(Unknown Source)

at java.awt.Component.processEvent(Unknown Source)

at java.awt.Container.processEvent(Unknown Source)

at java.awt.Component.dispatchEventImpl(Unknown Source)

at java.awt.Container.dispatchEventImpl(Unknown Source)

at java.awt.Component.dispatchEvent(Unknown Source)

at java.awt.KeyboardFocusManager.redispatchEvent(Unknown Source)

at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(Unknown Source)

at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(Unknown Source)

at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(Unknown Source)

at java.awt.DefaultKeyboardFocusManager.dispatchEvent(Unknown Source)

at java.awt.Component.dispatchEventImpl(Unknown Source)

at java.awt.Container.dispatchEventImpl(Unknown Source)

at java.awt.Window.dispatchEventImpl(Unknown Source)

at java.awt.Component.dispatchEvent(Unknown Source)

at java.awt.EventQueue.dispatchEventImpl(Unknown Source)

at java.awt.EventQueue.access$000(Unknown Source)

at java.awt.EventQueue$3.run(Unknown Source)

at java.awt.EventQueue$3.run(Unknown Source)

at java.security.AccessController.doPrivileged(Native Method)

at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)

at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)

at java.awt.EventQueue$4.run(Unknown Source)

at java.awt.EventQueue$4.run(Unknown Source)

at java.security.AccessController.doPrivileged(Native Method)

at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)

at java.awt.EventQueue.dispatchEvent(Unknown Source)

at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)

at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)

at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)

at java.awt.EventDispatchThread.pumpEvents(Unknown Source)

at java.awt.EventDispatchThread.pumpEvents(Unknown Source)

at java.awt.EventDispatchThread.run(Unknown Source)

I can’t understand anything, but this looks interesting:

at org.jivesoftware.spark.ui.ChatRoom.checkForEnter(ChatRoom.java:698)

at org.jivesoftware.spark.ui.ChatRoom.access$300(ChatRoom.java:90)

Maybe Spark is checking for Enter press, but can’t register it for showing that message was sent, though it is enough to send actual message on the background and add it to the transcript.

Btw, so far Spark restart is enough to mitigate this issue for some time. Log out and login doesn’t fix this error.

P.S. Wonder what would happen if Spark had “Send” button. Maybe it would be possible to show that message was sent, when sent with that button and not the Enter key.

Yup, the same error that i got on it’s time.



I have installed Openfire/Spark in my office. Every day about 500 people use it. We often experience similar problems.

These problems happen because when we start the program static fields (TO_COLOR, FROM_COLOR, NOTIFICATION_COLOR and ERROR_COLOR) of ChatManager class are initialized as null, as class is loaded before loadLookAndFeel function of org.jivesoftware.Spark class executed.

I first tried to do a check before using these field. For example, in org.jivesoftware.spark.ui.TranscriptWindow class in insertMessage method:

if (foreground != null) {

 StyleConstants.setForeground(styles, foreground);


It didn’t solve the problem, because similar problems arise elsewhere (alot places, where using these static fields).

I later realized the nature of the problem. It lies in startupPerformed event org.jivesoftware.SparkStartupListener class. It’s event used for XEP-0147, but sometimes and mostly during the program autoload this event occurs prior to start of basic program in org.jivesoftware.Spark. During the autoload the initialization of ChatManager fields is executed (prior to loadLookAndFeel function of org.jivesoftware.Spark class). But in this case the method is executed with an empty argument.

I solved the problem adding the following validation in org.jivesoftware.SparkStartupListener class:

old code:

final ChatManager chatManager = SparkManager.getChatManager();


new code:

if (args != null && !args.trim().isEmpty()) {

 final ChatManager chatManager = SparkManager.getChatManager();



I have had no problems since I did that.

I hope it works for you.

please consider making a unified diff (patch) file and posting it here for review/commit. thanks

Patch file attached.

SparkStartupListener.java.patch.zip (490 Bytes)

Ok, I posted your patch on your behalf to the ticket SPARK-1546 – someone will need to review it and make sure everything’s all good… but it’s a minor change so probably no big deal.

Just out of curiosity (i’ve only losely followed this thread) – what happens in your patch if args is null or empty? Nothing else is effected?

Nothing else is supposed. It’s not necessary.

Looks promising, awesome.

When a user experiences this problem, they seem to be able to spam the “alert” button without pause too, normally there is a delay before the button can be used again. Does this fix that too?

I will try to replace this piece of code on one of the user with this problem, if it works i will build a new msi for our whole company.

BTW, i understand how to replace the code, but how do i use the patch file?

Well, in Netbeans i can right click the source and choose Apply diff patch option. Depends on IDE being used. Not sure it will fix Alert, but i think this is possible as a “side effect”

Hmm, im a networking guy so none of that for me. I will just edit the files with notepad++… Thx for the info.

If you install TortiouseSVN (it’s free), you can right click the patch file --> Apply patch --> Browse to your downloaded source code --> tell it to apply for all files in the patch. Done… pretty easy.

Just wanted to say that I had this happening and deleting and then disabling conversation history seems to have temporarily resolved this issue.


Haven’t tried that, but restarting Spark is normally my quick fix.

I’ve updated the client for the person with the most problems using the patch mentioned earlier in this thread. So far no problems after a few days.

I am glad to hear there is a patch in the works. I just tried this approach erlier this morning after remembering a user had some “issues” with spark (i think it was slow etc…) and disabling history worked. Today’s user was more specific as the original post here. Disabling chat history worked for now. I will update if that changes.


@wroot : how can i read the error of spark if there’s something wrong ???