Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for feeding via bytebuffers #78

Open
TuomasKiviaho opened this issue Nov 13, 2022 · 2 comments
Open

Support for feeding via bytebuffers #78

TuomasKiviaho opened this issue Nov 13, 2022 · 2 comments

Comments

@TuomasKiviaho
Copy link

Jackson has had NonBlockingByteBufferJsonParser from 2.14.

Could NonBlockingParserbe upgraded to accommodate to ByteBufferFeeder to avoid having to do memory copying when source is ByteBuffer

@TuomasKiviaho
Copy link
Author

Currently JacksonResumableParser´ can't be extended to accommodate bytebuffers in similar way that JacksonNonblockingParser` does. I suggest changing the class at least as protected to allow inheritance in case the implementation is not fit to be included to the project.

There are couple of simple and backwards compatible ways how to enhance the JacksonResumableParser that I spotted to do repeatable doPare calls minimal state testing inside the tight loop.

  • JsonProvider could be held on to as an instance variable in the construction time since PrimitiveHolder treat is as immutable already.
  • Test only if there are JsonTokens to begin with since JsonSaxHandler does the context state testing. Currently it's return values are not utilized as tight loop breaking points. Immediate stop should return true from the method and break from the tight loop immediately.
  • EOF handling could be moved out from the method to both parse and resume methods where it belongs by returning null from the doPare
  • NOT_AVAILABLE should not pause the context but should instead break from the tight loop by returning false to conform with the return values of those from JsonSaxHandler .

With these changes the doPare could be called multiple times when the feeding process has not been ended either by EOF or immediate stop and context pausing can hence be handled outside of the tight-loop to better meet the demands back-propagation concept of reactive streaming for instance.

@wanglingsong
Copy link
Owner

Hi @TuomasKiviaho , Thanks so much for the suggestion. I will look into it this week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants