Hi Ben,
thanks for your response! I was thinking about a custom type coercer -
seems like the best bet in the short term. We will have another go at
identifying the underlying cause as well - would be better if we could
solve it at source.
Cheers,
Adriaan
On Tue, 5 Oct 2021 at 22:23, Ben Weidig
Hi Adriaan,
we're using Ajax/JSONObject, too, but haven't seen such problems so far.
But I'm sure it's highly dependent on the context, and concurrent requests
count.
For your problem, if you can't switch out the underlying data structure,
you might get around it by writing a custom type coercer
Hi Ben,
thanks for the reply! No, the json object is not stored in the session, but
it does traverse a lot of different components. The most likely cause seems
to be from separate threads that we use to speed up data loading during a
request, but we have not been able to pin it down - naturally we
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 i
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:
