Fix intermittent ConcurrentModificationException (#92)

[sbraconnier]

Fix Intermittent ConcurrentModificationException using getMergedConnectorMessage (#92)

[jonbartels]

@sbraconnier - I see what the change does and I see how it could prevent a concurrent modification exception.

Can you link to an issue or discussion or other info about why or when the issue happens?

[sbraconnier]

@jonbartels Sorry I only added the reference in the title. I updated the PR description to link the original issue.

[tonygermano]

I think this may not actually fix the issue. I can't find any indication that this method would be called concurrently from two threads. The stack traces from the two nextgen issues don't have mirth versions on them, but they indicate that the problem occurs on one of these two lines (the line numbers shifted in mirth 4.4.0):

engine/donkey/src/main/java/com/mirth/connect/donkey/model/message/Message.java

Lines 155 to 156 in 75ca77c

	responseMap.putAll(connectorMessage.getResponseMap());
	channelMap.putAll(connectorMessage.getChannelMap());

The map being modified concurrently is the argument to the putAll method. Since this method doesn't update that map, that means there is probably another thread that isn't trying to call this same method, but is instead updating the responseMap or channelMap for the same connectorMessage while this method is trying to read it.

[sbraconnier]

Hmm you're right. I think it would be nice to let the synchronized block since the method is building the mergedConnectorMessage field and it will ensured that 2 threads won't initialized it concurrently. I'll take a look at the putAll calls.

[tonygermano]

My guess without digging into it too much is that a destination queue thread is updating either the responseMap or the connectorMap while the post-processor is trying to build the mergedConnectorMessage.

It may be that just setting a couple retry attempts within this method if a ConcurrentModificationException is thrown would take care of it since this is pretty rare, and that wouldn't introduce the performance penalties associated with synchronization between threads.