NoResponseException with Smack 4.0.0-SNAPSHOT when joining MUC Room

I’m runnining into an issue with Smack 4.0.0-SNAPSHOT:

//////////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////

My code:

public class Test {

private static final Logger logger = LoggerFactory.getLogger(Test.class.getName());

public static void main(String[] args){

//XMPPService is a wrapper to obtain a XMPPConnection

XMPPService xmpp = new XMPPService(“USERNAME@HOSTNAME”, “PASSWORD”);

XMPPConnection connection;

try {

connection = xmpp.connect();

} catch (XMPPException e) {

logger.error(“Could not connect: XMPPException”, e);


} catch (SmackException e) {

logger.error(“Could not connect: SmackException”, e);


} catch (IOException e) {

logger.error(“Could not connect: IOException”, e);



assert connection.isSecureConnection();

logger.debug(“connection established and authentication successfull!”);

MultiUserChat muc = new MultiUserChat(connection, “ROOMNAME@MUCSERVICE”);

muc.addMessageListener(new ConsumerMUCMessageListener());

try {


} catch (NoResponseException e) {

logger.error(“Could not join conversation: IOException”, e);

} catch (XMPPErrorException e) {

logger.error(“Could not join conversation: IOException”, e);

} catch (NotConnectedException e) {

logger.error(“Could not join conversation: IOException”, e);


logger.debug(“joined conversation!”);

try {

muc.sendMessage(“Hello world!”);

} catch (NotConnectedException e) {


} catch (XMPPException e) {




private static class ConsumerMUCMessageListener implements PacketListener {

private int messageCount=0;

public void processPacket(Packet packet) {

if (packet instanceof Message) {

Message msg = (Message)packet;“Received message number : " + (messageCount++)+”: "+msg.getBody());




public int getMessageCount() {

return messageCount;




//////////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////

The output:

apr 02, 2014 5:15:30 PM org.jivesoftware.smack.initializer.UrlProviderFileInitializer initialize

INFO: Loading providers for file [classpath:org.jivesoftware.smackx/extensions.providers]

17:15:31.841 [main] DEBUG freely.main.Test - connection established and authentication successfull!

17:15:36.852 [main] ERROR freely.main.Test - Could not join conversation: IOException

org.jivesoftware.smack.SmackException$NoResponseException: null

at org.jivesoftware.smack.PacketCollector.nextResultOrThrow( 77) ~[smack-core-4.0.0-SNAPSHOT.jar:4.0.0-SNAPSHOT]

at org.jivesoftware.smackx.muc.MultiUserChat.join( ~[smack-extensions-4.0.0-SNAPSHOT.jar:4.0.0-SNAPSHOT]

at org.jivesoftware.smackx.muc.MultiUserChat.join( ~[smack-extensions-4.0.0-SNAPSHOT.jar:4.0.0-SNAPSHOT]

at freely.main.Test.main( ~[classes/:na]

17:15:36.852 [main] DEBUG freely.main.Test - joined conversation!

17:15:36.864 [Smack Listener Processor (0)] INFO freely.main.Test - Received message number : 0: Hello world!

//////////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////

My question:

Why would “muc.join(NICKNAME)” throw a NoResponseException? It appears the user has successfully joined the room, when I look at the server. Also, it takes ± 5seconds before the “join” call returns, but the user was in the room immediatly at the beginning. Am I doing something wrong?

It appears that the server’s MUC component is not sending the “self-presence” as described in XEP-0045 7.2.3. What software does provide the MUC component?

The XMPP server I’m testing against is Openfire 3.9.1. Isn’t Smack 4.0.0-SNAPSHOT compatible with that version of Openfire?

Maybe try to increase the SmackConfiguration.setPacketReplyTimeout().

it takes ± 5seconds before the “join” call returns

On the one hand, that is strange, on the other hand did we experience similar long timeouts, when using BOSH. Do you use BOSH?

Good point. It could also be that the delay until the self-presence is send is simply to greater then the default packet reply timeout. @Dirk: As CSH suggested, and try to increase the default packet reply timeout.

Especially the XEP-45 self-presence reply can take a while. It may be a good idea to make the packet reply timeout in MUC.join() configurable or add some extra seconds to the default reply timeout

No I’m not using BOSH as far as I’m aware…

Also I did as proposed, and I’ve added the SmackConfiguration.setPacketReplyTimeout(10*1000) call (which I assumes means a timeout of 10 seconds). The behaviour I now get is that it takes 10 seconds before the error is thrown, instead of 5, which makes me assume that the Openfire server just never sends the message that Smack expects…

Is the XEP-0045 message really neccessary? Because at this point, everything works, except for the error that is thrown, and the “join()” functions that blocks for 5 seconds (or whatever I configure with SmackConfiguration.setPacketReplyTimeout()).

Yes, the self-presence stanza is neccessary.

You could try to send enable Smack.DEBUG to trace the exchanged stanzas between client and server, and verify that the self-presence is in fact not send or if it’s not the PacketFilter that doesn’t catch the stanza.

How would I enable Smack.DEBUG? I’ve included smack-debug-4.0.0-SNAPSHOT.jar but that’s it?

I’ve added a PacketListener and a PacketFilter and here is the new output:


Hard to tell what exactly is going on with the supplied information. I see a presence with an error (presence id=‘ntx6J-3’) but without the outgoing stanzas it can’t say more about it.

Basically what one want in such situations is a full trance of the exchanges stanzas and the involved code, so that can be compared with the specification (XEP-0045, in that case).

Ok I’ve added the floowing statement to enable debugging:

ConnectionConfiguration config = new ConnectionConfiguration(, this.port);


The output of the Smack Debug Window:

Is there anything else I can send you that would help in resolving this issue?

P.s. All the code required to replicate my case is found here:

I’m using the Smack 4.0.0-SNAPSHOT from the Maven repository (Sonatype). The POM.xml i’m using can be found here:

The server I’m using is Openfire 3.9.1

The key stanzas which are received appear to be


Hello world!

The error conditions why you get an 405/not-allowed are explained in XEP-45. That is also the reason the message sent to the MUC is returned with an error recipient-unavailable.

What makes me wonder is why you don’t get a XMPPErrorException with the not-allowed wrapped within. That is what I would expect to happen when 8G8Kg-7 is received. The packet filter created in MUC.join() should match and therefore the stanza should get collected. But as you said you get a NoResponseException this is obviously not the case.

From the stanza trace it appears that the MUC is not created, because of the not-allowed error when you try to join the MUC.

Next thing you could do, is to attach an debugger and set an breakpoint at MUC.join() and maybe also at the packet collectors. I really like to know why you get an NoResponseException when you in fact get an error response which should cause an XMPPErrorException. Of course this doesn’t tells you why you can’t join MUC.

Here you can see the output of eclipse, and Gajim next to each other.

The user with nickname “DirkJavaTest” clearly joined the room, was able to send messages to the room (see Gajim window) and receives messages from the room (see Eclipse console)

Why would it throw that error when everything else works fine?

MUC.join() should throw an XMPPErrorException when it receives an presence stanza with an error from the MUC it tried to join. I can’t answer why this isn’t the case without debugging it and I don’t have time to do so atm. That’s why I suggested that you should try to find the cause.

I also can’t answer why you get the presence stanza with the error in the first palce, mostly because it’s send by the server.

Just a quick thought: Have you tried it with a MUC with an JID that does not contain an underscore? Or some other MUC component?

Ok thank you for your help so far, I’ll see if I find the problem, and if I do, I’ll share it in this thread.

Found a thread which seems to be about a similar issue.

Maybe this can be explained by the issie i just described in this issue:

The error responses sent by the MUC service from the server are sent, with a different From address, then the one used for sending the request.

request uses

the response contains a without the nickname.

hi flow i have the same issue but i m using the prosody server.


Yes i using bosh configuration

BOSHConfiguration conf = BOSHConfiguration.builder().setUsernameAndPassword(“xyz”, “123”)

.setFile("/http-bind/").setHost(“”).setPort(5280).setServiceName(“10.0 .0.10”)

.setSendPresence(true).setSecurityMode(SecurityMode.required).setDebuggerEnable d(true)


XMPPBOSHConnection connection = new XMPPBOSHConnection(conf);

// XMPPBOSHConnection connection = new XMPPBOSHConnection(“xyz”,“123”,false,“”,5280,"/http-bind",“”) ;


try {




i increased the packet time out to 15 seconds rather i m getting the

org.jivesoftware.smack.SmackException$NoResponseException: No response received within reply timeout. Timeout was 15000ms (~15s). Used filter: AndFilter: (FromMatchesFilter (full): xyz@, StanzaTypeFilter: org.jivesoftware.smack.packet.Presence).