We discovered a condition under which MultiUserChat.enter() blocks forever, resulting in the MUC for this address being unusable. This is the stack trace we observed (a few hours after the call to createOrJoin):
java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(firstname.lastname@example.org/Native Method) - waiting on <no object reference available> at java.lang.Object.wait(email@example.com/Object.java:328) at org.jivesoftware.smackx.muc.MultiUserChat.enter(MultiUserChat.java:427) - waiting to re-lock in wait() <0x0000000717561e20> (a org.jivesoftware.smackx.muc.MultiUserChat$3) at org.jivesoftware.smackx.muc.MultiUserChat.createOrJoin(MultiUserChat.java:546) - locked <0x000000071755f510> (a org.jivesoftware.smackx.muc.MultiUserChat) at org.jivesoftware.smackx.muc.MultiUserChat.createOrJoin(MultiUserChat.java:521) - locked <0x000000071755f510> (a org.jivesoftware.smackx.muc.MultiUserChat)
In our case this probably happened because the PacketReader thread died with an exception and the reflected self presence was never processed. The thread running enter() does a wait(0) until the stanza listener is called. Using a finite timeout and failing if the reflected self presence still hasn’t been processed should solve the problem. If you agree I can work on a PR.