Community
Participate
Working Groups
Created attachment 199121 [details] stack trace We are currently running into a concurrency issue during initialisation of EclipseLink/Gemini JPA that happens from time to time depending on timing. Our application asynchronously modifies system properties during startup. If, by chance, EclipseLink/Gemini JPA initialisation happens at the same time, an exception is thrown and EntityManagerFactory is not returned. Here is an excerpt of the stack trace: Caused by: Exception [EclipseLink-28018] (Eclipse Persistence Services - @VERSION@.@QUALIFIER@): org.eclipse.persistence.exceptions.EntityManagerSetupException Exception Description: Predeployment of PersistenceUnit [TestPersistenceUnit] failed. Internal Exception: java.util.ConcurrentModificationException at org.eclipse.persistence.exceptions.EntityManagerSetupException.predeployFailed(EntityManagerSetupException.java:221) ... 31 more Caused by: java.util.ConcurrentModificationException at java.util.Hashtable$Enumerator.next(Hashtable.java:1031) at org.eclipse.persistence.internal.sessions.PropertiesHandler$Prop.getPrefixValuesFromMap(PropertiesHandler.java:233) at org.eclipse.persistence.internal.sessions.PropertiesHandler$Prop.getPrefixValuesToApply(PropertiesHandler.java:291) at org.eclipse.persistence.internal.sessions.PropertiesHandler.getPrefixValuesLogDebug(PropertiesHandler.java:140) at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.initOrUpdateLogging(EntityManagerSetupImpl.java:1982) at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.updateLoggers(EntityManagerSetupImpl.java:730) at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.predeploy(EntityManagerSetupImpl.java:1147) ... 30 more I will attach the full stack trace and the zip file with a workspace setup that can be used to reproduce the situation.
Created attachment 199122 [details] setup to reproduce the issue Here is a ZIP file with two projects that can be used to reproduce the issue.
Created attachment 199123 [details] patch proposal Here is a patch proposal created on 2.3 branch. We would like to see the fix included into 2.3.1.
My concern about this patch is there is no upper bound on the number of iterations in the loop. As a result, if the ConcurrentModificationException is happening for some reason we have not anticipated, this will potentially lock up the application.
Created attachment 199639 [details] updated patch proposal Here is an updated patch with termination of the loop after 100 times.
I will take a look - assigned to myself.
Discussed with Shaun Smith: I think his suggestion is an improvement: The right solution is to not get an iterator() for the entry set but to get an array via toArray(). toArray() will be synchronized on the properties *HashTable*. Once we have a clean copy of the entries we can iterate over that without having to worry about modifications to the System.properties.
Created attachment 200153 [details] patch proposal V3 Shaun's proposal is definitely the best one. Thanks. Here is the updated patch that reflects the proposal.
Tom, will you have time to review the patch and include it into 2.3.1? Thanks and best regards, Ed
My current plan is to look at this fairly soon and get it included in 2.3.1.
Submitting fix without regression test case - our regression framework currently won't handle the scenario described above. Checked into 2.3.1 and trunk Reviewed by: Tom Ware - reviewed user-submitted fix Tested with JPA LRG
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
