Concurrency error causes IllegalStateException on BeanPropertyMap

[franboragina]

Hi,
I suspect a concurrency error maybe similar to Issue #1578.
It appears randomly on fresh tomcat startup, with first REST calls through CXF jaxrs.
I was not able to reproduce on development environment.

BeanPropertyMap.java - line 728:
throw new IllegalStateException("Illegal state: property '"+prop.getName()+"' missing from _propsInOrder");

Somewhere _hashArea and _propsInOrder are losing the correlativity objects they own.

The only clue:

Debugging I have seen in both arrays an "@id" ObjectIdValueProperty bean but different objects in memory,
so that
if (_propsInOrder[i] == prop) {
miserably fails :(
(BeanPropertyMap.java - line 724)

Files attached:

1. StackTraceError.log
   error.log

2. The JSON received. (It is always the same json and the same java model.)
   response.json.log

3. The Customized ObjectMapper we use
   CustomObjectMapper.java.log

I hope your help, thank you very much

Sorry for my English!!

[cowtowncoder]

Which Jackson version?

[franboragina]

It has happened to us with Jackson 2.8.7 and we updated to 2.9.5 and also happens El mar., 8 de mayo de 2018 18:59, Tatu Saloranta <notifications@github.com> escribió:

…

Which Jackson version? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2027 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AlSMmr2MjMDuCff5eAVrG2eR-twwaPa_ks5twc7fgaJpZM4T2-30> .

[cowtowncoder]

@franboragina Thank you.

This sounds unfortunate, thank you for reporting it. I can not think of obvious reason, but I think there are ways to improve handling of _propsInOrder to reduce mutability further.
But the big problem is that of trying to reproduce the issue since I can not get this to occur locally.

[cowtowncoder]

Ok. One possible source of problem was mutability of BeanPropertyMap, in one specific case (when adding a new property). I changed that to make a proper full copy, just like javadocs claimed should already have been done.
I don't have a way to verify whether this solves the problem but it seems like it should help.
For now I assume this does solve the problem; change will be in 2.9.6.
If not, may be reopened if verified against 2.9.6 once that is released (it is not yet out), or against build from 2.9 branch.

For what it is worth, code in master (for 3.0) already had rewritten version of this class, which should have same problem.

[franboragina]

@cowtowncoder
Thank you very much for your time and congratulations for your great project

[cowtowncoder]

Thank you! And thank you for reporting this in the first place. That's how we can project work better for everyone.

[tiguchi]

@cowtowncoder Sorry for resurrecting an old issue, but I've been consistently running into this crash recently (version 2.13.3) and I wanted to check back with you whether the DeserializerCache is perhaps statically stored somewhere, or whether it's always created from scratch per ObjectMapper instance.

A bit of context:

• Tomcat application server
• ...running a web application that uses Spring Beans for autowiring a preconfigured ObjectMapper instance using the "singleton" scope
• Updates are deployed to the still running application server, so the old version of the application is replaced with the new one while still running
• I can verify locally when I trigger a redeploy, that the factory method for creating the singleton scoped object mapper is called on every redeploy

I introduced a few DTO changes recently where new properties were added, and since then I kept running into that crash. After a Tomcat restart the problem disappeared, so I assume something was holding on to the old deserializer cache which didn't know the new properties, yet.

I also never ran into this problem before until recently, despite having deployed many updates like that for a couple of years now. I'm a bit at a loss how to troubleshoot, so I just wanted to ask for clarification if the Jackson library stores anything statically

[cowtowncoder]

No, there are no static references to it anywhere; every ObjectMapper has its own separate copy.
I try very hard not to have any static singletons that could leak state across mappers and this cache definitely would be problematic.