powered by Jive Software

Pade upgraded from 1.7.2 to 1.7.3: Unable to start 2 person meeting

We’ve been happily using and upgrading both Openfire and Pade and find the meetings to be perfect!

Except until last week :sob:

We updated Openfire 4.7.3 to 4.7.4 and Pade 1.7.2 to 1.7.3 and found that 2 person meetings (from the same computer) failed with both users disconnected without explanation. We reverted to the previous versions of both Openfire and Pade and confirmed that out meetings worked flawlessly, as before.

We then updated Pade ONLY and the problem returned. The first guest initiates the meeting (exactly as in the past) and becomes the moderator. When the second guest (from an incognito tab) attempts to join the meeting, BOTH guests are disconnected with the dreaded ‘something went wrong’ message.

The openfire log contains nothing meaningful. There are lots of INFO and a couple of WARNing messages. The only ERROR messages are:
ERROR [pool-monitoring3]: org.jivesoftware.util.XMLProperties - Unable to save XML properties; no file specified
and the timing seems to have nothing to do with the meeting failure(s)

I can provide a full log for the time surrounding the error if this helps.

Our installation is quite boring, except that we have the LOBBY enabled.

I would be very grateful for any direction.

Thanks in advance

Enable debug/trace logging, restart server and look at your log file

The “unable to save XML properties” error is unrelated. This is a known issue with the latest version of the monitoring plugin. It has been registered under tracker Periodic "org.jivesoftware.util.XMLProperties - Unable to save XML properties" errors · Issue #242 · igniterealtime/openfire-monitoring-plugin · GitHub

We’re now wondering if Pade 1.7.3 may have introduced something related to Room Affiliation and Ownership … and here’s why:

  • we’ve updated Fedora and completely reinstalled Openfire 4.7.4 and Openfire-Pade 1.7.3
  • we’ve configured Pade so that anyone can create a room and others can join (we use this for adhoc meetings for staff and clients and it works wonderfully … thank you again)
  • we’ve found that the first person creating the meeting room, works exactly as we’re expecting and as we’ve experience in the past; however when a second person joins the meeting BOTH are disconnected with a vague ‘something happened’ message and then this process repeats as both users attempt to reconnect.
  • we’ve been looking through the logs in search of an error message that might give direction, and we can’t see anything suggesting an ERROR

But we do see this:

2022.12.05 08:50:00 INFO [socket_c2s-thread-3]: org.jivesoftware.openfire.muc.MUCRoom - Applying affiliation change for 2n9b28k8s6@localmeet2.aimlocal.ca
2022.12.05 08:50:00 INFO [socket_c2s-thread-3]: org.jivesoftware.openfire.muc.MUCRoom - New affiliation: owner
This is the expected behavior and the same message that we’ve seen in the past when a new room is created

2022.12.05 08:50:58 INFO [socket_c2s-thread-3]: org.jivesoftware.openfire.muc.MUCRoom - Applying affiliation change for 5s8xwd05nk@localmeet2.aimlocal.ca
2022.12.05 08:50:58 INFO [socket_c2s-thread-3]: org.jivesoftware.openfire.muc.MUCRoom - New affiliation: owner
2022.12.05 08:50:59 INFO [socket_c2s-thread-2]: org.jivesoftware.openfire.muc.spi.MultiUserChatServiceImpl - removing chat room:lm2|org.jivesoftware.openfire.muc.MUCRoom
This is NOT expected. Both users are kicked out and receive the dreaded ‘Unfortunately something went wrong. trying to reconnect …’ message
We are expecting that the second (and subsequent) users join a room that is already owned … by the first person in

2022.12.05 08:51:26 INFO [socket_c2s-thread-3]: org.jivesoftware.openfire.muc.MUCRoom - Applying affiliation change for 4v79gsa1a7@localmeet2.aimlocal.ca
2022.12.05 08:51:26 INFO [socket_c2s-thread-3]: org.jivesoftware.openfire.muc.MUCRoom - New affiliation: owner
2022.12.05 08:51:27 INFO [socket_c2s-thread-3]: org.jivesoftware.openfire.muc.MUCRoom - Applying affiliation change for 39p0cj4k7r@localmeet2.aimlocal.ca
2022.12.05 08:51:27 INFO [socket_c2s-thread-3]: org.jivesoftware.openfire.muc.MUCRoom - New affiliation: owner
2022.12.05 08:51:27 INFO [socket_c2s-thread-4]: org.jivesoftware.openfire.muc.spi.MultiUserChatServiceImpl - removing chat room:lm2|org.jivesoftware.openfire.muc.MUCRoom
2022.12.05 08:51:32 WARN [httpbind-worker-2]: org.jivesoftware.openfire.websocket.XmppWebSocket - Failed to deliver packet; socket is closed:

And the cycle repeats …

2022.12.05 08:51:50 INFO [socket_c2s-thread-3]: org.jivesoftware.openfire.muc.MUCRoom - Applying affiliation change for 8aobyobfo9@localmeet2.aimlocal.ca
2022.12.05 08:51:50 INFO [socket_c2s-thread-3]: org.jivesoftware.openfire.muc.MUCRoom - New affiliation: owner
2022.12.05 08:51:56 INFO [socket_c2s-thread-3]: org.jivesoftware.openfire.muc.MUCRoom - Applying affiliation change for 4lqm7dz1bp@localmeet2.aimlocal.ca
2022.12.05 08:51:56 INFO [socket_c2s-thread-3]: org.jivesoftware.openfire.muc.MUCRoom - New affiliation: owner
2022.12.05 08:51:57 INFO [socket_c2s-thread-4]: org.jivesoftware.openfire.muc.spi.MultiUserChatServiceImpl - removing chat room:lm2|org.jivesoftware.openfire.muc.MUCRoom
2022.12.05 08:52:01 WARN [httpbind-worker-4]: org.jivesoftware.openfire.websocket.XmppWebSocket - Failed to deliver packet; socket is closed:
And the cycle repeats …

We kind of assuming that something has changed and we need to re-configure to prevent the second user from trying to take ownership. But we don’t know what we’re looking for; and frankly we’re just guessing.

Can you provide some direction?

Thanks in advance.