ConcurrentModificationException in Netty S2S

I’m confident that this was caused by the additionalNamespaces collection being stored in a field defined on the Connection interface. We’re treating it as an instance field, but it is a static field.

Aside from the above, I just identified another modification of the collection where I only expected a read. That’s a different potential cause, and possibly easier to fix.

This problem is in the StanzaHandler code, that adds the http://etherx.jabber.org/streams namespace if it’s not already in the collection.

I have added a snippet of a log-file that ends with the concurrent modification issue.

What I think that I see happen here is:

• the remote domain jabbers.one sending a ping request to the local domain igniterealtime.org (and the conference service domain, which I think we can ignore for now). This happens on pre-existing inbound connection A.

• the local domain apparently does not have an outbound connection, and is establishing a new one: connection B

• not shown in the data, but Openfire typically performs a jabber:iq:version query when creating a new outbound connection. I'm assuming that this request was sent on connection B. In any case, the answer to this query is received on connection A.

• This is received at roughly the same time when the stream of connection B is still being set up (the stream open element is shown, as are the inbound features).

• Connection A is being closed as a reaction to a concurrent modificition (the subject of this Jira ticket).

This suggests that the namespaces that are being received on connection B are being used by connection A. I do not think that’s desirable - I expected two distinct sets to be used, one for each connection.

This revolves around access to org.jivesoftware.openfire.Connection#additionalNamespaces - a collection that stores namespaced that were detected on the opening stream element on an inbound connection. These namespaces are used when subsequent element of the stream (which are also its child elements) are parsed.

With this usage pattern in mind, it is unexpected that there is concurrent read/write interaction with this collection: the collection is created/populated by parsing the root stream element, and should be read/accessed when parsing its child elements. This seems safe. However, the ConcurrentModificationException indicates that something unexpected happens.

Possible causes include (but may not be limited to):

• concurrent processing of a root element and its child elements that are received on the same connection.

• the additionalNamespaces collection is somehow accessed by more than one connection.