Re: [sqlite] clocks in SQLite

[Roman Fleysher]

Thank you for pointing the 24 hours. I did not notice the day change. 

Now, I have no idea how this can happen. I will investigate more. 

Roman


From: Graham Holden [sql...@aldurslair.com]
Sent: Tuesday, May 15, 2018 3:39 PM
To: Roman Fleysher
Cc: General Discussion of SQLite Database
Subject: Re: [sqlite] clocks in SQLite

Tuesday, May 15, 2018, 7:49:32 PM, Roman wrote:

> Job 1847 ends at 16:44:11 and job 1852 starts at 18:47:46 (and
> actually subsequently dies as evidenced by its stop being NULL).

How do you KNOW that your program didn't spend 2 hours 3 minutes
either not noticing job 1847 had finished, or deciding what to do next
once it had noticed? Do you KNOW, say, that THAT process didn't die
and was restarted?

> Next job, 2283, is started BEFORE job 1852. RunID is INTEGER PRIMARY
> KEY and for this purpose is auto incrementing. Jobs are also running
> on other nodes, therefore runID is not contiguous for this node.

Job 2283 starts NEARLY 24 hours AFTER job 1852!

> runID  hostname   start   stop
> -- -- --- ---
> 1841   loginnode4 2018-05-14 07:53:42 2018-05-14 10:05:41
> 1843   loginnode4 2018-05-14 10:05:41 2018-05-14 12:18:05
> 1845   loginnode4 2018-05-14 12:18:05 2018-05-14 14:30:50
> 1847   loginnode4 2018-05-14 14:30:50 2018-05-14 16:44:11
> 1852   loginnode4 2018-05-14 18:47:56
> 2283   loginnode4 2018-05-15 18:18:59

> Could it indicate other issues than the clock itself? It is highly
> unlikely that clock happened to jump forward at the time when 1852
> was finishing (at 16:44:11). Time of start of 2283 looks
> correct, agrees with my watch, because I started this job manually.

> Roman

Regards,
Graham Holden


___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] clocks in SQLite

[Graham Holden]

Tuesday, May 15, 2018, 7:49:32 PM, Roman wrote:

> Job 1847 ends at 16:44:11 and job 1852 starts at 18:47:46 (and
> actually subsequently dies as evidenced by its stop being NULL).

How do you KNOW that your program didn't spend 2 hours 3 minutes
either not noticing job 1847 had finished, or deciding what to do next
once it had noticed? Do you KNOW, say, that THAT process didn't die
and was restarted?

> Next job, 2283, is started BEFORE job 1852. RunID is INTEGER PRIMARY
> KEY and for this purpose is auto incrementing. Jobs are also running
> on other nodes, therefore runID is not contiguous for this node. 

Job 2283 starts NEARLY 24 hours AFTER job 1852!

> runID  hostname   start   stop
> -- -- --- ---
> 1841   loginnode4 2018-05-14 07:53:42 2018-05-14 10:05:41
> 1843   loginnode4 2018-05-14 10:05:41 2018-05-14 12:18:05
> 1845   loginnode4 2018-05-14 12:18:05 2018-05-14 14:30:50
> 1847   loginnode4 2018-05-14 14:30:50 2018-05-14 16:44:11
> 1852   loginnode4 2018-05-14 18:47:56
> 2283   loginnode4 2018-05-15 18:18:59

> Could it indicate other issues than the clock itself? It is highly
> unlikely that clock happened to jump forward at the time when 1852
> was finishing (at 16:44:11). Time of start of 2283 looks  
> correct, agrees with my watch, because I started this job manually.

> Roman

Regards,
Graham Holden



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] clocks in SQLite

[Warren Young]

On May 15, 2018, at 12:49 PM, Roman Fleysher  
wrote:
> 
> Next job, 2283, is started BEFORE job 1852.

No it isn’t.  Check the date:

> 1852   loginnode4 2018-05-14 18:47:56
> 2283   loginnode4 2018-05-15 18:18:59

It’s starting nearly 24 hours later, the next day.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users