Jackson JSON Processor

NPE in deseralization, probably a race condition

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.4.1
  • Fix Version/s: 1.3.5, 1.4.3
  • Component/s: None
  • Labels:
    None
  • Environment:
    Java 1.6 mac osx and ubuntu
  • Number of attachments :
    0

Description

I'm seeing an occasional NPE in our tests, it only happens every so often, I fear this might be a concurrency bug. Note, the same message is deseralized 3 times simultaneously with the same ObjectMapper instance.

java.lang.NullPointerException: null
at org.codehaus.jackson.map.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:116)
[jackson-mapper-asl-1.4.1.jar:1.4.1]
at org.codehaus.jackson.map.deser.SettableBeanProperty$MethodProperty.deserializeAndSet(SettableBeanProperty.java:202)
[jackson-mapper-asl-1.4.1.jar:1.4.1]
at org.codehaus.jackson.map.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:344)
[jackson-mapper-asl-1.4.1.jar:1.4.1]
at org.codehaus.jackson.map.deser.BeanDeserializer.deserialize(BeanDeserializer.java:281)
[jackson-mapper-asl-1.4.1.jar:1.4.1]
at org.codehaus.jackson.map.ObjectMapper._readMapAndClose(ObjectMapper.java:1282)
[jackson-mapper-asl-1.4.1.jar:1.4.1]
at org.codehaus.jackson.map.ObjectMapper.readValue(ObjectMapper.java:885)
[jackson-mapper-asl-1.4.1.jar:1.4.1]

The json is

"{"origin":{"number":"40411","id":1},"command":"post","user":{"userName":"bobthebuilder","lastChange":0,"createTime":0,"id":1},"placeCode":{"loca":"loca","id":1},"processed":"hello
world","textMessageId":1,"userMobileDevice":{"number":"6071234567","userId":1,"carrierId":1,"id":1},"carrier":{"operatorId":null,"id":1},"raw":"post
@loca hello world","sentDate":0}"

Activity

Hide
Benjamin Darfler added a comment -

Seen in 1.4.2 as well.

Show
Benjamin Darfler added a comment - Seen in 1.4.2 as well.
Hide
Tatu Saloranta added a comment -

Fortunately fixing this was quite easy: fix applied to trunk, 1.3 and 1.4 branches (for 1.5.0, 1.4.3 and 1.3.5 releases).

Caching of deserializers is now done as a two-step process, where intermediate incomplete deserializers are not exposed to other threads. Locking during deserializer construction is bit more coarse-grained, but for typical use cases should not greatly matter (since construction is only done if no cached version is found, i.e. first time deserializer is needed for type).

Unit test added passes for all fixed branches, please let me know if issues are still found.

Show
Tatu Saloranta added a comment - Fortunately fixing this was quite easy: fix applied to trunk, 1.3 and 1.4 branches (for 1.5.0, 1.4.3 and 1.3.5 releases). Caching of deserializers is now done as a two-step process, where intermediate incomplete deserializers are not exposed to other threads. Locking during deserializer construction is bit more coarse-grained, but for typical use cases should not greatly matter (since construction is only done if no cached version is found, i.e. first time deserializer is needed for type). Unit test added passes for all fixed branches, please let me know if issues are still found.
Hide
Tatu Saloranta added a comment -

Releases in 1.3.5, 1.4.3.

Show
Tatu Saloranta added a comment - Releases in 1.3.5, 1.4.3.

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: