Yep, that is what it is supposed to be doing. I'd have to log all the json and then try to backtrack...
I'll have to turn up some logging and see if I can catch it. Thanks... On Mar 13, 3:58 pm, Andrew Badera <and...@badera.us> wrote: > We can't answer your question for you since we have no idea what > you're receiving. What does the streaming response look like that your > consumer is tripping over? Capture it in association with log events. > > ∞ Andy Badera > ∞+1 518-641-1280Google Voice > ∞ This email is: [ ] bloggable [x] ask first [ ] private > ∞ Google me:http://www.google.com/search?q=andrew%20badera > > > > On Sat, Mar 13, 2010 at 5:23 PM, briantroy <brian.cosin...@gmail.com> wrote: > > We are doing are last bit of testing before cutting over to the > > streaming API and we see occasional errors: > > > PHP Warning: [json] (json_encode_r) double INF does not conform to > > the JSON spec, encoded as 0. in /root/src/justsignal-twitter-stream/ > > twitter-track-class.php on line 154 > > PHP Warning: [json] (json_encode_r) double -INF does not conform to > > the JSON spec, encoded as 0. in /root/src/justsignal-twitter-stream/ > > twitter-track-class.php on line 154 > > > Seems pretty odd to me because we are decoding the JSON (to look for > > limit messages) and then just popping the JSON onto a queue. If we > > don't find an ID or a LIMIT we log the JSON - all of this happens > > before the JSON encode ever happens. > > > We are getting 0 JSON logged (because it doesn't have an ID or LIMIT). > > > Anyone else seen this? > > > Thanks! > > > Brian Roy
