Non-blocking parsing issue

[sdeleuze]

When doing some integration tests before releasing Spring Framework 5.0 RC3 expected to be released tomorrow, we found some errors that could be related to the non-blocking parsing introduced by Jackson 2.9.0.pr4 via issue #57 that we leverage. The error could be on Spring side, but since it seems to be at byte level it is maybe on Jackson side. In any case, some guidance would really help us. It seems to affect the last fields of an object to deserialize.

This issue can be reproduced with this project: https://github.com/sdeleuze/demo-java-jackson-non-blocking/tree/master. The test works with springBootVersion = '2.0.0.M2' which does not use non-blocking parsing and fails with springBootVersion = '2.0.0.BUILD-SNAPSHOT' which uses non-blocking parsing.

The error we have with non-blocking parser is the following like if we missed some data:

java.lang.AssertionError: expectation "expectNext(Event{id='0', start=-999999999-01-01, end=+999999999-12-31})" failed (expected value: Event{id='0', start=-999999999-01-01, end=+999999999-12-31}; actual value: Event{id='0', start=-2735938-12-30, end=null})

In MiXiT application, the issue is visible in almost all JSON based integration unit tests, including with errors like that:

JSON decoding error: Can not deserialize instance of java.util.ArrayList out of START_OBJECT token; nested exception is com.fasterxml.jackson.databind.exc.MismatchedInputException: Can not deserialize instance of java.util.ArrayList out of START_OBJECT token
 at [Source: UNKNOWN; line: -1, column: -1] (through reference chain: mixit.model.User["links"])))

Any thoughts?

[cowtowncoder]

No immediate thoughts, sounds like a possible bug. I will look into this, and timing is good -- hoping to close 2.9.0 this week.

[sdeleuze]

Ok thanks, our code triggering the parsing is here.

[cowtowncoder]

I think I would need a way to reproduce the problem -- possibly just input document, although probably related to how input is accessed (that is, buffer boundaries).
I don't really have good guesses where the problem might be.

[sdeleuze]

It seems indeed related to how input is accessed, and I am not sure how to reproduce it in another way than running the integration test of this repro project I provided. Any chance you could use it to debug how Jackson is handling the data?

[sdeleuze]

Maybe more details : you should be able to debug test unit test in Eclipse or IDEA with just importing the project. If you prefer command line, you can just run the app with ./gradlew bootRun (that won't show this issue which is on client side but will allow you to see the data by requesting http://localhost:8080/events with curl) or reproduce the issue by running ./gradlew test (you may be able to attach a debugger if needed).

[sdeleuze]

After digging into this issue it seems it was on Spring side, and we have fixed it. Jackson side seems to be ok so feel free to release 2.9.0 ;-)

[cowtowncoder]

@sdeleuze Ah ok. Sorry I missed part of running the test -- wasn't sure if the whole project was to be run etc.

But fortunately you managed to locate it; much appreciated. Hope to proceed with the release, after going once more over projects to see if I'm forgetting anything critical wrt API.