I'll definitely post if I come across more. It's usually just more of a Charlie Brown *augh* than a show-stopper by any means. And then like you said, it eventually sorts itself out.
I did consider switching to XML as that always seems to be the cache copy that's up-to-date, but then realized I would have to update a variety of other things to deal with the proper data types. Thanks for the detail! dpc On Mar 11, 11:05 am, Alex Payne <[email protected]> wrote: > Snapshots in time of the XML output and JSON output are helpful. But I > certainly believe that there could be such discrepancies. They tend to > arise when our database replication lag increases. Some client > requests UncachedUserA in XML, and those inaccurate counts get "frozen > in time" until a cache invalidation event occurs. Then the replication > lag sorts itself out, and someone requests UncachedUserB and sees the > correct values. > > It's a very frustrating property of our system's architecture at the > moment, but one we're working on solutions for. > > > > On Wed, Mar 11, 2009 at 10:09, Damon C <[email protected]> wrote: > > > I've seen this from time-to-time before, but could never really pin it > > down to specific users or timeframes. > > > In any case, I frequently see inconsistencies between the data in XML > > and JSON representations. The example I came across last night was > > with the ActiveRainMaker account. The caches have since caught up (un) > > fortunately, and I don't have another example. > > > In this case, though, the XML had a friends_count of ~1800 while the > > JSON had a friends_count of ~800. I'm not really sure what else I can > > provide and I probably didn't post before b/c it just sounds like > > complaining. ;) > > > Thanks! > > > dpc > > > -- > > Damon P. Cortesi > > Security Guy, Twitter Apps > > www. tweetstats | tweepsearch | tweetsum .com > > -- > Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
