deanhiller
commented
10 years ago - can we get the more full stack trace(the one above only has the top line) as I do want to look at the specific code to see if I can see anything.
- A disconnect in the middle would cause the message not to be parsed at all in json(csv upload is different). Since it actually got to parsing, we know there was no network issue. The way it works is that for json posts.....all of the information is sent and in the http header exists the size of the bytes of the payload(basic http stuff. actual http header is called Content-Length)....once that is read, it reads the payload and once the payload is successfully read, it then calls our controller method with the entire json payload. If you have a network issue, our controller will not be called at all. Since our controller is called, we know there is no network error and then the parsing fails.
What we can do however is the following!!!! Once you give me the stack trace I can verify I modified the correct code as I now log the bad json in that exception message you are reading. NOTE: This json should already be logged in a previous log statement as well from this specific code in databus...
log.info("posting json="+json);
thanks, Dean
kbrems
I have an Android app that sends data files every minute to databus. Every once in a while I get back an http error 400 (bad request). However when I try to send this file again either through the same code or via curl, it uploads fine.
When I looked at the databus log file for the time period of the error I see
WARN: There was a problem parsing the JSON request. org.codehaus.jackson.JsonParseException: Unexpected end-of-input: expected close marker for ARRAY (from [Source: java.io.StringReader@898e150; line: 1, column: 1]) at [Source: java.io.StringReader@898e150; line: 1, column: 24607] at org.codehaus.jackson.JsonParser._constructError(JsonParser.java:1433) ~[jackson-core-asl-1.9.8.jar:1.9.8]
But the file is valid json (I ran it through jsonlint and it also sends correctly the 2nd time). Given that databus is reporting the error on the first character, and this is a 26K file, my guess is that the problem is really some kind of temporary network connection issue and it is not actually getting the complete file, or not getting any file in the http POST, but the databus code is not catching that at a higher level and is sending bad or empty data to the parser, which generates the 400 error.
The problem is that then I can't detect the difference between a legitimately bad file and a temporary connection error, in which case I want to retry sending the file.