0

I am facing this weird issue where the api is throwing concurrent modification exception because of javax.validation issue.

    java.util.ConcurrentModificationException: null
    at java.util.HashMap$HashIterator.nextNode(HashMap.java:1445) ~[na:1.8.0_265]
    at java.util.HashMap$ValueIterator.next(HashMap.java:1474) ~[na:1.8.0_265]
    at org.eclipse.persistence.jpa.PersistenceProvider.isLoadedWithReference(PersistenceProvider.java:464) ~[eclipselink-2.6.1.jar:2.6.1.v20150916-55dc7c3]
    at javax.persistence.Persistence$PersistenceUtilImpl.isLoaded(Persistence.java:154) ~[javax.persistence-2.1.0.jar:2.1.0]
    at org.hibernate.validator.internal.engine.resolver.JPATraversableResolver.isReachable(JPATraversableResolver.java:56) ~[bean-validator-2.2.0.jar:5.0.0.Final]
    at org.hibernate.validator.internal.engine.resolver.DefaultTraversableResolver.isReachable(DefaultTraversableResolver.java:130) ~[bean-validator-2.2.0.jar:5.0.0.Final]
    at org.hibernate.validator.internal.engine.resolver.SingleThreadCachedTraversableResolver.isReachable(SingleThreadCachedTraversableResolver.java:46) ~[bean-validator-2.2.0.jar:5.0.0.Final] [1 skipped]
    at org.hibernate.validator.internal.engine.ValidatorImpl.isReachable(ValidatorImpl.java:1307) ~[bean-validator-2.2.0.jar:5.0.0.Final]
    at org.hibernate.validator.internal.engine.ValidatorImpl.isValidationRequired(ValidatorImpl.java:1292) ~[bean-validator-2.2.0.jar:5.0.0.Final]
    ... 49 common frames omitted
Wrapped by: javax.validation.ValidationException: HV000041: Call to TraversableResolver.isReachable() threw an exception.
    at org.hibernate.validator.internal.engine.ValidatorImpl.isReachable(ValidatorImpl.java:1316) ~[bean-validator-2.2.0.jar:5.0.0.Final]
    at org.hibernate.validator.internal.engine.ValidatorImpl.isValidationRequired(ValidatorImpl.java:1292) ~[bean-validator-2.2.0.jar:5.0.0.Final]
    at org.hibernate.validator.internal.engine.ValidatorImpl.validateConstraint(ValidatorImpl.java:475) ~[bean-validator-2.2.0.jar:5.0.0.Final]
    at org.hibernate.validator.internal.engine.ValidatorImpl.validateConstraintsForDefaultGroup(ValidatorImpl.java:424) ~[bean-validator-2.2.0.jar:5.0.0.Final]
    at org.hibernate.validator.internal.engine.ValidatorImpl.validateConstraintsForCurrentGroup(ValidatorImpl.java:388) ~[bean-validator-2.2.0.jar:5.0.0.Final]
    at org.hibernate.validator.internal.engine.ValidatorImpl.validateInContext(ValidatorImpl.java:340) ~[bean-validator-2.2.0.jar:5.0.0.Final]
    at org.hibernate.validator.internal.engine.ValidatorImpl.validateCascadedConstraint(ValidatorImpl.java:635) ~[bean-validator-2.2.0.jar:5.0.0.Final]
    at org.hibernate.validator.internal.engine.ValidatorImpl.validateCascadedConstraints(ValidatorImpl.java:524) ~[bean-validator-2.2.0.jar:5.0.0.Final]
    at org.hibernate.validator.internal.engine.ValidatorImpl.validateInContext(ValidatorImpl.java:349) ~[bean-validator-2.2.0.jar:5.0.0.Final]
    at org.hibernate.validator.internal.engine.ValidatorImpl.validateCascadedConstraint(ValidatorImpl.java:635) ~[bean-validator-2.2.0.jar:5.0.0.Final]
    at org.hibernate.validator.internal.engine.ValidatorImpl.validateCascadedConstraints(ValidatorImpl.java:524) ~[bean-validator-2.2.0.jar:5.0.0.Final]
    at org.hibernate.validator.internal.engine.ValidatorImpl.validateParametersInContext(ValidatorImpl.java:916) ~[bean-validator-2.2.0.jar:5.0.0.Final]
    at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:240) ~[bean-validator-2.2.0.jar:5.0.0.Final]
    at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:198) ~[bean-validator-2.2.0.jar:5.0.0.Final]
    at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1095) [webapp-runner.jar:na] [28 skipped]
    at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:672) [webapp-runner.jar:na]
    at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1502) [webapp-runner.jar:na]
    at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1458) [webapp-runner.jar:na]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_265]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_265]
    at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [webapp-runner.jar:na]
    at java.lang.Thread.run(Thread.java:748) [na:1.8.0_265]

The stack trace doesn't say anything about which validation in the bean is causing the issue.

projectile
  • 61
  • 7
  • How often does this occur? Looks like a timing issue as the code involved as the EclipseLink PerisistenceProvider is iterating over persistence units it manages to determine if the entity attribute was loaded as part of the validation process. Something must be adding/removing from the list of persistence units while this is occurring - feel free to file a bug, but is very strange unless you've got a lot of deploy/undeploy operations going on in your environment. – Chris Apr 20 '21 at 13:54

2 Answers2

1

It looks like the stacktrace is being formatted in an idiosyncratic way by ... something.

The normal way to display it is to display the primary exception first, followed by the cause (or wrapped) exception chain. But what you have shown us has the wrapped exception followed by the exception that is wrapping it.

So that means that the ConcurrentModificationException is causing the ValidationException ... not the other way around.

Unfortunately, this doesn't explain what is actually going on.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • com.foo.mapper.CustomExceptionMapper:Unexpected Bean Validation problem. This is the exception header after which concurrent exception is printed. Will this help in anyway ? I clearly don't see any code as part of my api which can cause concurrent modification exception. The stack trace as well says it comes from hibernate. So I am suspecting it's a library problem – projectile Apr 20 '21 at 11:08
0

Clearly Exception stack trace is saying that Concurrent modification exception is occuring in hashmap. Concurrent modification exception can happen if you use Iterators while traversing map values or API which are not thread safe like the Generic Hashmap object. Try using concurrent hashmap and your problem should be resolved.