Add support for non-blocking ("async") JSON parsing

[cowtowncoder]

(migrated from http://jira.codehaus.org/browse/JACKSON-39 -- note, high vote count)

---

(suggested by Dimitri M on user list)

There are use cases where it'd be good to be able to feed input to parser, instead of trying to provide an input stream for parser to read from. This would cover use cases where input comes in chunks; for example, part of logical document in one chunk, then after a delay (perhaps in a separate request) another one and so forth. In these cases it may be difficult to implement InputStream (Reader etc) abstraction; instead, it would be better if application could feed (push) data to parser.
But if so, parser must be able to indicate cases where no data is YET available (but may become available).

This is similar to how Aalto Xml processor (http://www.cowtowncoder.com/hatchery/aalto/index.html) operatesd in its async mode. However, since Json is much simple format than xml, implementation might be simpler.

Based on my experiences with Aalto, implementation is a non-trivial thing however. One problem is that even UTF-8 decoding needs to be somewhat aware of chunk boundaries, so in the end a separate parser may be required: this because current parser uses blocking to handle these split cases. A smaller problem is that of indicating "not-yet-available" case – this can probably be handled by introducing a new member in JsonToken enumeration.

[chhetri]

+1. Please implement it if you can.

[cowtowncoder]

Heh. Unless I have personal need, or someone pays me to do it, I doubt I'll ever work on this.

But perhaps someone else has the itch. Always willing to help.

[dpratt]

+1

I'm using Aalto right now to parse XML - I've bolted it onto an Akka IO/Scala Delimited Continuations framework that I wrote that allows you to access the API as if it were regular blocking StAX code. I'd love to be able to migrate our JSON handling to the same framework.

[cowtowncoder]

For what it is worth, I did start writing async parser for Smile backend, as that would be marginally easier.

@dpratt I'd be very interested in learn more about your use of Aalto, including feedback, challenges, things you learnt. Maybe you could send email to my gmail address (tsaloranta)? This could even eventually help with JSON equivalent, if things worked out well. What I really need more than anything else is someone to collaborate, to make it less likely I write something that does not get used.

[akaigoro]

I wrote a simple JSON non-blocking parser (as a part of a parser for Javon - Json's extention): https://github.com/rfqu/Javon . I can help to embed it into Jackson codebase.

[cowtowncoder]

We are always happy to accept contributions, if you want to tackle this problem. In case of Jackson, interface would need to be via JsonParser, to work together with other components (although there is a significant problem with databinding anyway...).

[akaigoro]

If you mean com.fasterxml.jackson.core.JsonParser, then it is technically impossible. It contains methods like nextToken(), which would block until input data are available, destroying the idea of non-blocking parser. The interface has to be turned inside out: parser should have method putChar(char nextChar), and transfer parsed data to a next stage which has interface similar to JsonGenerator.

[dpratt]

Why not have nextToken return the (already defined and standard Jackson
token type) NOT_AVAILABLE when more input is required?

On Tue, Aug 6, 2013 at 3:06 PM, Alexei Kaigorodov
notifications@github.comwrote:

If you mean com.fasterxml.jackson.core.JsonParser, then it is technically
impossible. It contains methods like nextToken(), which would block until
input data are available, destroying the idea of non-blocking parser. The
interface has to be turned inside out: parser should have method
putChar(char nextChar), and transfer parsed data to a next stage which has
interface similar to JsonGenerator.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/57#issuecomment-22207073
.

[akaigoro]

It is defined, but not used. And I cannot see easy way to use it: when the consumer should awake and try to read next token again? It should be notified some way, but then it's natural to pass new token with the notification. Then, how do you think the consumer should save and restore its state, if it calls to nextToken () from recursive methods?

[dpratt]

I've used the same pattern quite successfully using Aalto - basically, you
have to build up an Iteratee-like structure that parses a non-blocking
stream of events. Then, you have another bit that feeds the parser on
demand (when bytes are available), translates those to tokens, and feeds
the iteratee with the tokens. At each feed step, the iteratee either
signals that it's done or returns an object with the capability to consume
another token. Using these primitives, you can build up some very
sophisticated parsers - I'm about to publish a library that does this for
XML (using Aalto). The equivalent for JSON would actually be quite a bit
more simple to implement.

On Tue, Aug 6, 2013 at 4:40 PM, Alexei Kaigorodov
notifications@github.comwrote:

It is defined, but not used. And I cannot see easy way to use it: when the
consumer should awake and try to read next token again? It should be
notified some way, but then it's natural to pass new token with the
notification. Then, how do you think the consumer should save and restore
its state, if it calls to nextToken () from recursive methods?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/57#issuecomment-22213710
.

[cowtowncoder]

@rfqu Please have a look at Aalto, like @dpratt suggested, if you have time -- yes, minor modification is needed, but JsonToken already has NOT_AVAILABLE (I did anticipate need for it); and the other part for feeding input is not a big addition. I understand that you are thinking of push style interface (SAX); but while this can be useful for some use cases, there is not much value for adding such an interface in Jackson in my opinion. For a new stand-alone library it is not a bad way to go of course, and doing it that way is slightly easier for implementors. But not so much for users.

@dpratt Yes, exactly! There are challenges at higher levels, so data-binding would need to change a lot, from pull- to push model most likely. But at core level it is doable.

[cowtowncoder]

@rfqu On how caller knows more is available: typically (at least with Aalto), caller both feeds new data and iterates; so it will feed a chunk of bytes, then iterate over tokens until there are no more available. Then get new data (possibly waiting, via NIO callbacks).

I wrote a bit about using Aalto in non-blocking mode 2.5 years ago, see:

http://www.cowtowncoder.com/blog/archives/2011/03/entry_451.html

[dpratt]

I can say that having at the very least a JsonParser implementation that
only implemented nextToken() (and perhaps just returns defaults for all the
other methods) would be incredibly useful for me. I have several cases in
which I need to parse very large JSON documents (on the order of 8-15 megs
in memory as a raw byte stream) and the ability to do it incrementally
would be massively helpful.

We could even implement a JsonParser2 interface that extends JsonParser and
adds the push methods to consume new byte arrays.

On Tue, Aug 6, 2013 at 5:39 PM, Tatu Saloranta notifications@github.comwrote:

@rfqu https://github.com/rfqu Please have a look at Aalto, like @dpratthttps://github.com/dprattsuggested, if you have time -- yes, minor modification is needed, but
JsonToken already has NOT_AVAILABLE (I did anticipate need for it); and
the other part for feeding input is not a big addition. I understand that
you are thinking of push style interface (SAX); but while this can be
useful for some use cases, there is not much value for adding such an
interface in Jackson in my opinion. For a new stand-alone library it is not
a bad way to go of course, and doing it that way is slightly easier for
implementors. But not so much for users.

@dpratt https://github.com/dpratt Yes, exactly! There are challenges at
higher levels, so data-binding would need to change a lot, from pull- to
push model most likely. But at core level it is doable.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/57#issuecomment-22217359
.

[akaigoro]

I looked Aalto and found that to save its state, parser defines several dozens of constants. It is no fun to program that way.
Then, your JsonParser delivers a stream of tokens and so is actually a scanner. Scanners work closely with parsers, and their interaction should not bother theirs user. You, however, offer me to implement a scanner alone with given interface while corresponding parser also is not implemented, and I am not sure the proposed interface is a right choice.
In short, I was not going to make a contribution to your project, and you did not inspire me. I still am ready to help if you decide to use my code, but I don't want to reconstruct it myself to follow your style.

[cowtowncoder]

@rfqu You are free not to contribute, I was just outlining what kind of contribution would make sense, based on YOUR offer to help. I don't know where you get that pissy attitude however; that is unnecessary.
My job is not to "inspire" you; this is voluntary collaboration (or not) of peers. While I appreciate your offer for the code, it is very important that any code fits within general design of library. This does not seem to be the case here.

I wish you best of luck with your projects however; and given that it can do non-blocking parsing the way you like it, I hope interested users find it.

As to Aalto: it is just a (conceptually!) simple state machine; and if there was a state machine generator to use, it'd be much simpler to write. I don't greatly care if something is simple for implementors to write; pull-style is much easier for users to use and that what counts most to me. But as I said, you are free to explore other options that are more to your liking.