Hi,
I’ve a simulation where I get those warn messages:
11:30:01.836 [WARN ] i.g.h.a.AsyncHandlerActor - Request ‘SyncUpdate’ failed: jsonPath($…syncid).exists failed, could not prepare: Could not parse response into a JSON object: Unable to parse JSON object
The current character read is ‘"’ with an int value of 34
Unable to parse JSON object
line number 1
index number 1
Maybe the JSON-Response is too big?!
Greetz
Niko
Which version of Gatling do you use?
Which version of JDK?
Could you provide a sample of your JSON string, please?
- Which version of Gatling do you use?
- Which version of JDK?
- Could you provide a sample of your JSON string, please?
Could you confirm that it works fine with this replacement for gatling-http, please?
https://docs.google.com/file/d/0B1zTVlhQrNiyV3pqejI2WmlwdmM/edit
Can you reproduce every time, without load testing?
If so, would you mind debugging with me?
The problem is in the streaming parser mode that’s triggered when the body is too big, and could be anywhere: in the parser itself, in the InputStream implementation, etc…
With the attached version it works 
Did you change anything?
I didn’t fix anything: the problem is still here. I just increased the threshold from 1Mb to 10Mb so the parser now used the full body String of your 2.2Mb JSON document instead of an InputStream from the byte chunks.
I will investigate.
Thanks for reporting.
Okay thx for the support and quick response.
Just one thing: your document is huge and you should try to reduce the scope of your search.
In the sample you provided, syncid only appears as a root child, so $.syncid would be much better than $…syncid that scans the full tree.
Indeed a performance killer my fault. Thx once again
$.data.syncid actually
I could reproduce and confirm that this is a parser bug: https://github.com/RichardHightower/boon/issues/98
I think this will get fixed pretty soon, stay tuned.
Fixed!
I advice you update your snapshot, will be way better for your use case of huge JSON payloads.
Verified fixed thx
Thanks for your feedback!
Also, we’ve put lots of efforts in this upcoming release in JSON support and JsonPath.
So we’d really appreciate if you could provide feedback on how it behaves for you, like is memory and CPU usage reasonable even when dealing with huge files such as yours.
Cheers,
Stéphane
Yes of course and I just read the comments from your reported issue at boon 
lol the guy seems to be cool but I think he hates our “responses from hell”
Yep, Rick is a very nice guy, but he… speaks his mind.
He originally developed his parser for his own usage: very short messages for low latency systems.
I keep on pressing him with complex use cases he didn’t anticipate.
He’s grumpy at first, but he loves challenges 
LOL
Getting more sleep now. Less grumpy.
Hi,
I now have a simliar issue with both (boon and preferjackson) in 2.0.0rc1:
jsonPath($.timestamp).exists failed, could not prepare: Could not parse response into a JSON object: Unexpected character (’<’ (code 60)): expected a valid value (number, String, array, object, ‘true’, ‘false’ or ‘null’) at [Source: java.io.ByteArrayInputStream@4b41956d; line: 1, column: 2]
jsonPath($…data).exists failed, could not prepare: Could not parse response into a JSON object: Unable to determine the current character, it is not a string, number, array, or object The current character read is ‘<’ with an int value of 60 Unable to determine the current character, it is not a string, number, array, or object line number 1 index number 0 ^
the response is starting this way:
the httprequest is a multipart post, for other httprequests the jsonPath query works well.
greetings,
Martin
Hi Martin,
Well… there’s nothing strange about it : jsonPath works on a JSON input, not on a JSON string hidden somewhere in a HTML page
In your case, you have to fall back to regular expressions.