Spark UI freezes when opening chat window(s)

I’ve been having this problem off and on again for months now. The problem persists in 3.0.0 beta (build from source), but was also present in earlier versions.

For me, the Spark application windows will often, but not always, completely freeze when a new chat window tab is opened. When the application freezes, I can activate the windows of Spark (select them and move them around), but I cannot interact with them at all: typing doesn’t work, mouse clicks do nothing. I can’t even close the windows by clicking the (x) icon in the title bar.

The problem pops up regularly, but not consistently, when I configure Spark to automatically join a couple of MUC rooms after logging in.

I wonder if this problem is related to my environment. I’m using Ubuntu 20.04, OpenJDK Runtime Environment (build 1.8.0_292-8u292-b10-0ubuntu1~20.04-b10).

This might have to do with loading the chat history of a newly-opened window. When I modify the implementation of org.jivesoftware.spark.ui.TranscriptWindow#add to return immediately (without doing anything), then the problem seems to disappear.

Update: I’ve narrowed it down further to the last invocation of org.jivesoftware.spark.ui.CustomTextEntry#addTo that is performed when receiving the subject of the chatroom. Specifically, the ‘setCaretPosition’ method invocation seems where things freeze.

Update II:
What’s interesting is, with that line disabled, this is the content of my text area after joining the room (all content that’s displayed is message history, there are no live messages added yet).

(10:56) guus.der.kinderen: So the tests are failing for 7, not 6?
(10:58) fishbowler: Tests are failing locally for me for 7.0.6 tag (which is also the tip of the 7.x.x branch)
(10:59) fishbowler: Not tried master (8.0.0 unreleased)
(10:59) guus.der.kinderen: Haargh, client issues prevent me from doing anything. 😡
(12:02) akrherz changed the subject to "Where Hope Springs Eternal ... Smack 4.4.2, Openfire 4.6.4, Spark 3.0.0-beta"
(11:00) guus.der.kinderen: Would you mind popping into discuss@conference.conversejs.org and ask jcbrand ?
(11:02) fishbowler: Sure!
(11:03) guus.der.kinderen: Tx
(11:20) fishbowler: Got another approach - just grabbing the tar from https://github.com/conversejs/converse.js/releases/tag/v7.0.6 - JC must've been happy with that, right?

Note that the subject is not the last line - even though it should have been sent by Openfire as the last stanza in response to a MUC room join. The timestamp of the subject probably is the timestamp of when it akrherz actually set that subject (which was many days ago).

My users are using Spark 2.9.4 and they were experiencing freezes when connecting to a room. Solution - Show only a specific number of messages, for me 1000 messages and Spark does not freeze!)

Isn’t that 30 by default? Showing the entire history would be nasty, on old rooms.

25
But I have 10 users in room there who make about 100-150 messages a day and they need to watch history for the last 5-6 days)

Understood - but I’m having the problem on a server (Ignite’s) where this setting is the default. So, switching it to 1000 would probably make the problem… worse?

Yep,probably we have different problems …

I had similar problems (UI freezes) with Ubuntu & OpenJDK 1.8. Not seen them anymore after switching to OpenJDK 11.

I’ve raised SPARK-2234 for this issue. After some experimentation, I found that the problem disappears when I modify the code to stop setting the caret to the bottom of the screen, every time a new line of history is being added (when a new chat is opened, it is automatically populated with the chat’s history, if there’s any).

Fix provided in SPARK-2234: Fix 'freeze' when joining a new chat by guusdk · Pull Request #645 · igniterealtime/Spark · GitHub

I have time today to experiment with Spark.
I took the last nightly build(Other versions of SPark freeze too) and typed 10,000 characters into the text 150-200 times in the test chat. After that, I can’t connect to the room because Openfire kicks me right away.
It also did not help me to limit the visibility of only 25 messages.

This can be a problem because if you flood in a room, then no one will be able to enter it.

2021.07.21 18:57:09 WARN [socket_c2s-thread-24]: org.jivesoftware.openfire.nio.ConnectionHandler - Closing connection due to exception in session: (0x0000200C: nio socket, server, /172.16.15.10:54039 => /172.16.3.13:5222)
java.io.IOException: Closing session that seems to be stalled. Preventing OOM
at org.jivesoftware.openfire.net.StalledSessionsFilter.filterWrite(StalledSessionsFilter.java:57) ~[xmppserver-4.5.4.jar:4.5.4]
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753) ~[mina-core-2.1.3.jar:?]
at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49) ~[mina-core-2.1.3.jar:?]
at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146) ~[mina-core-2.1.3.jar:?]
at org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:138) ~[mina-core-2.1.3.jar:?]
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753) ~[mina-core-2.1.3.jar:?]
at org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:746) ~[mina-core-2.1.3.jar:?]
at org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:570) ~[mina-core-2.1.3.jar:?]
at org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:515) ~[mina-core-2.1.3.jar:?]
at org.jivesoftware.openfire.nio.NIOConnection.deliverRawText0(NIOConnection.java:360) ~[xmppserver-4.5.4.jar:4.5.4]
at org.jivesoftware.openfire.nio.NIOConnection.close(NIOConnection.java:225) ~[xmppserver-4.5.4.jar:4.5.4]
at org.jivesoftware.openfire.nio.ConnectionHandler.exceptionCaught(ConnectionHandler.java:164) [xmppserver-4.5.4.jar:4.5.4]
at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.exceptionCaught(DefaultIoFilterChain.java:987) [mina-core-2.1.3.jar:?]
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextExceptionCaught(DefaultIoFilterChain.java:706) [mina-core-2.1.3.jar:?]
at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1100(DefaultIoFilterChain.java:49) [mina-core-2.1.3.jar:?]
at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.exceptionCaught(DefaultIoFilterChain.java:1110) [mina-core-2.1.3.jar:?]
at org.apache.mina.core.filterchain.IoFilterAdapter.exceptionCaught(IoFilterAdapter.java:114) [mina-core-2.1.3.jar:?]
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextExceptionCaught(DefaultIoFilterChain.java:706) [mina-core-2.1.3.jar:?]
at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1100(DefaultIoFilterChain.java:49) [mina-core-2.1.3.jar:?]
at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.exceptionCaught(DefaultIoFilterChain.java:1110) [mina-core-2.1.3.jar:?]
at org.apache.mina.core.filterchain.IoFilterAdapter.exceptionCaught(IoFilterAdapter.java:114) [mina-core-2.1.3.jar:?]
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextExceptionCaught(DefaultIoFilterChain.java:706) [mina-core-2.1.3.jar:?]
at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1100(DefaultIoFilterChain.java:49) [mina-core-2.1.3.jar:?]
at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.exceptionCaught(DefaultIoFilterChain.java:1110) [mina-core-2.1.3.jar:?]
at org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:97) [mina-core-2.1.3.jar:?]
at org.apache.mina.core.session.IoEvent.run(IoEvent.java:89) [mina-core-2.1.3.jar:?]
at org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTask(OrderedThreadPoolExecutor.java:766) [mina-core-2.1.3.jar:?]
at org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTasks(OrderedThreadPoolExecutor.java:758) [mina-core-2.1.3.jar:?]
at org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.run(OrderedThreadPoolExecutor.java:697) [mina-core-2.1.3.jar:?]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_272]

This seems to be a different problem than the one I reported. I suggest we create a new Jira issue for this.