Pattern cache is not thread safe

[marcust]

I just had that thrown in my face:

java.util.ConcurrentModificationException: null
	at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1225)
	at graphql.validation.constraints.standard.PatternConstraint.cachedPattern(PatternConstraint.java:86)
	at graphql.validation.constraints.standard.PatternConstraint.runConstraint(PatternConstraint.java:74)
	at graphql.validation.constraints.AbstractDirectiveConstraint.runConstraintOnDirectives(AbstractDirectiveConstraint.java:155)
	at graphql.validation.constraints.AbstractDirectiveConstraint.runValidationImpl(AbstractDirectiveConstraint.java:136)
	at graphql.validation.constraints.AbstractDirectiveConstraint.runValidation(AbstractDirectiveConstraint.java:127)
	at graphql.validation.rules.TargetedValidationRules.runValidationImpl(TargetedValidationRules.java:131)
	at graphql.validation.rules.TargetedValidationRules.walkObjectArg(TargetedValidationRules.java:181)
	at graphql.validation.rules.TargetedValidationRules.runValidationImpl(TargetedValidationRules.java:147)
	at graphql.validation.rules.TargetedValidationRules.runValidationRules(TargetedValidationRules.java:121)
	at graphql.validation.schemawiring.FieldValidatorDataFetcher.get(FieldValidatorDataFetcher.java:47)

this is due to this in my schema

    country: String! @Pattern(regexp: "[A-Z][A-Z]")

and as we are running our tests in parallel that might actually happen that it is hit twice by different threads. I guess in real life that does not happen because you will not have so many requests hit at once without any warming up period which makes the pattern be cached already, but still.

If you have static maps, they should be thread safe.

[dwybourn]

We're running into this same issue, is there any work around for this?

[heowc]

This issue was addressed by #65

[dondonz]

Closing as #65 has been merged