StdSubtypeResolver is not thread safe (possibly due to copy not being made with ObjectMapper.copy())

[tjwilson90]

Version 2.11.0

java.util.ConcurrentModificationException
	at java.base/java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:719)
	at java.base/java.util.LinkedHashMap$LinkedKeyIterator.next(LinkedHashMap.java:741)
	at com.fasterxml.jackson.databind.jsontype.impl.StdSubtypeResolver.collectAndResolveSubtypesByTypeId(StdSubtypeResolver.java:194)
	at com.fasterxml.jackson.databind.deser.BasicDeserializerFactory.findTypeDeserializer(BasicDeserializerFactory.java:1597)
	at com.fasterxml.jackson.databind.DeserializationContext.findRootValueDeserializer(DeserializationContext.java:497)
	at com.fasterxml.jackson.databind.ObjectMapper._findRootDeserializer(ObjectMapper.java:4669)
	at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:4478)
	at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3471)

[cowtowncoder]

That is very odd: there should be no way that particular StdSubTypeResolver instance would be used concurrently in a way for this to happen, since underlying Set is _registeredSubtypes and that is only assigned during configuration of ObjectMapper, but not changed when mapper is being used (it must be set before usage).

So this is somehow due to specific usage. Two possibilities come to mind:

1. Something tries to re-configure ObjectMapper at point when it is already being used (not supported usage, but 2.x can not really prevent -- 3.0 makes this impossible)
2. A copy is made with ObjectMapper.copy(), but StdSubtypeResolver isn't copied, and thereby mapper instances remain coupled

It would be important to know what causes this, to be able to reproduce the problem.
That would allow fixing it (if it's (2)) or at least pointing out problems with usage (if (1)).
Or possible something else I didn't think of.

[tjwilson90]

The codebase I'm seeing in does make potentially concurrent ObjectMapper.copy() calls on the same ObjectMapper, so that hypothesis seems likely. I don't see any re-configuration.

[cowtowncoder]

@tjwilson90 Ok good, thank you for verifying this. In that case I think copy() operation needs to make copy of StdSubtypeResolver to avoid this problem. It'd be great to have a unit test to show the issue, but these are bit involved to do. Maybe

src/test/java/com/fasterxml/jackson/databind/misc/ThreadSafety1759Test.java

could be used as an example to build a (at least sometimes?) failing case.

[cowtowncoder]

Fixed for 2.11.1 and 2.12.0; 3.0 (master) would not have this problem (SubTypeResolver already snapshottable).

[tjwilson90]

Thanks for the quick turnaround.