On Thu, 2010-12-09 at 17:05 -0500, Jay Dobies wrote: > When performing a CDS sync, we write out two CDS events to the mongo > DB, > "sync_started" and "sync_finished", with the actual sync occuring in > between. Then when you get the CDS event history, they are sorted by > timestamp (default to descending order). > > I have a few unit tests that check to make sure those are present. The > tests where sync throws an error are sporadically failing. > > From what I can tell, sometimes the history events are being returned > with the "sync_finished" occuring before the "sync_started" in the > event > list. I'm not entirely sure why. > > When the event is created to be saved, it's setting the timestamp to > datetime.datetime.now(). I'm wondering if that's not precise enough to > differentiate between two events created in rapid succession, as would > occur if that sync call immediately errors out. > > Is there something better I should be using for the value for the > timestamp?
where are the time stamps coming from? if it's the tasking sub system, I can't see how start > finish could possibly happen datetime.datetime.now() objects are accurate to the microsecond and should be using the glibc function: gettimeofday(). nothing more accurate is going to be available without some sort of custom implementation. the worst case scenario should be: start = finish. if it is not, I'm willing to bet there some discrepancy in the order of these values being set. -- Jason L Connor Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.890.8331 Freenode: linear RHCE 805010912355231 GPG Fingerprint: 46C1 7010 E89B C9C5 F430 380C F412 953F CC4E D7C1
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Pulp-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-list
