I doublechecked the time the server was started until the last time the processes were delayed and it was actually 24.74 (2137700 seconds). The processes were delayed for 5 minutes. However, that time period + the delay is still 9,483,647 ms, or 2.63 hours, short of the 2147483647 max signed 32-bit integer.
Also many people have this occur after several months, so the DELAY PROCESS code must be able to accommodate the milliseconds rollover, at least in general. If it’s related to that, it must be an interesting corner case. Jim Crate > On Jun 12, 2018, at 1:33 PM, Keisuke Miyako via 4D_Tech > <[email protected]> wrote: > > 22 days does sound suspicious; as if (no proof), > the scheduler is testing if milliseconds "minus" process up-time is "greater > than" delay time... > such logic would break when milliseconds expressed in signed 32-bit long > integer flips to negative, after 24 days. > (milliseconds is counted since system boot, not 4D launch) > >> 2018/06/13 4:43、Jim Crate via 4D_Tech <[email protected]> のメール： >> Our server (macOS 10.11, 4D 16.3 HF3 64-bit) hit this bug again last week >> after being up for about 22 days. > > > > > ********************************************************************** > 4D Internet Users Group (4D iNUG) > FAQ: http://lists.4d.com/faqnug.html > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:[email protected] > ********************************************************************** ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
