I haven't tried this, but you may be able to use the socket api with some
NTP client code to determine the actual clock skew of each instance and use
that to compensate.
Jeff
On Sun, Nov 3, 2013 at 4:06 PM, Kaan Soral wrote:
> Thanks for all your replies
>
> My usecase tolerates time differenc
Thanks for all your replies
My usecase tolerates time differences, as each item has a unique id which
is checked before applying, that's why I was able to detect it, otherwise
applied cache results would be off sometimes
One solution would be to delay stuff by 15 seconds etc, so that even if
t
It seems to be fixed, but at one point on a previous project we were seeing
clock skews of over 30 minutes.
On Saturday, November 2, 2013 7:33:32 AM UTC-4, timh wrote:
>
> I have at times experienced definite clock skews (I documented some up as
> much a minute in the early stages.)
>
> I person
I have at times experienced definite clock skews (I documented some up as
much a minute in the early stages.)
I personally think it is a mistake to design a solution that needs < 5 sec
clock accuracy with appengine.
T
On Saturday, November 2, 2013 12:32:43 PM UTC+8, Vinny P wrote:
>
> On Fri,
On Fri, Nov 1, 2013 at 9:44 PM, Kaan Soral wrote:
> I've been seeing the errors pop up, but it's always between datetime's
> that differ only by 2-3 seconds
> Than I remembered a *really* old discussion about instance time
> differences and it seems that the cause of these 2-3 second differences
I have a caching logic for datastore entities, the cache was invalidating
elements when changes are applied to the entity
The logic was
if change_time>cache_item_created: delete cache_item
It also checks whether the cache_item has been applied before and logs an
error if it does
I've been seeing
