Hi, is the JSONObject in the Session and do you have Session locking disabled? See https://tapestry.apache.org/session-storage.html#SessionStorage-SessionLocking
Changing the print-loop to check if keys still exist would just hide the underlying problem: using a data-structure concurrently that isn't designed to be used in a concurrent environment. Maybe you could use another type of thread-safe data structure in your session, and convert it to a JSONObject before sending it back to the client? Cheers, Ben On Tue, Oct 5, 2021 at 2:50 PM Adriaan Joubert <adriaan...@gmail.com> wrote: > Hi, > > we intermittently see coercion errors for JSONObject - which we use > frequently for ajax context information. > > The relevant bit of stack trace is > > - Caused by: 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 org.apache.tapestry5.json.JSONObject.print(JSONObject.java:805) > - at > org.apache.tapestry5.json.JSONCollection.toString(JSONCollection.java:46) > - at > org.apache.tapestry5.commons.internal.BasicTypeCoercions$1.coerce(BasicTypeCoercions.java:69) > - at > org.apache.tapestry5.commons.internal.BasicTypeCoercions$1.coerce(BasicTypeCoercions.java:65) > - at > org.apache.tapestry5.commons.services.CoercionTuple$CoercionWrapper.coerce(CoercionTuple.java:57) > > > Overlapping calls mean the json object is modified in one place while it is > written elsewhere - as the objects themselves are not thread safe, it is > quite messy to protect all possible writes. > > Copying the keys before the print loop, with a check that the value still > exists when printing, would narrow the window for this to happen > considerably. We could not think of any better solutions to solve this > problem, but any suggestions are welcome. > > Cheers, > > Adriaan >
