David, Thanks for posting the LogWorker code, it has been fun experimenting with it.
I have been testing only the preemptive test code. Running on a Mac Pro (Late 2013) with 6-Core Intel Xeon E5 , Mac OS X 10.12.6 4D 16.1 hotfix 2 , 64 bit app. ( Not server ) Yes, there is a bug in the code. Method: LogWorker_Kill ,need to add the line Log_Path:=“” // This is required to get the LogWorker_Start code to open the log again Even so, your code would crash interpreted before the Kill was ever sent. Putting in delay process in LogWorker_CallABunch_Preemptive, would get it to run interpreted. So, clearly there is a 4D bug here. Compiled, I am able to remove all the delay processes, and run it to completion. I do get some runtime errors about broken communication. Again, I can make them go away with some delay processes, something I was trying to avoid. So, I encourage you to take another look at this code. Dave Porter Tailored Solutions, Inc. Business Management Software for Label Converters http://www.labeltraxx.com/ > On Sep 25, 2017, at 7:57 AM, David Adams via 4D_Tech <[email protected]> > wrote: > > On Mon, Sep 25, 2017 at 12:04 PM, Epperlein, Lutz (agendo) via 4D_Tech < > [email protected]> wrote: > I asked because we use a little own implementation of writing log files. > This is all before V16. We use semaphores to avoid race conditions while > writing to the file. > And one of our first projects after updating to V16 should be the rewriting > of this code using workers. So I'm a bit disappointed to hear that. > > Yes, centralizing a log writer seems like the most obvious use of a worker, > so I also was disappointed. But perhaps I'm wrong? It would not be the > first time that I've done something stupid. Just in case I'm missing > something obvious, I've posted a copy of the test database I've used to > demonstrate the bug here: > > http://www.4dcompanion.com/LogWorker.zip > > It's a crude test database. What I was doing is compiling it and running > LogWorker_CallABunch_Coop or LogWorker_Test_Preemptive. > > The test isn't to see if you can use CALL WORKER to execute code that > passes a log entry to a worker. > You can. > > The test isn't to see if you can then keep the log file open just in the > worker to avoid contention on the file. > You can. > > The test is to see what happens when you need to "roll" the log. Namely, > close the current log, rename it and open a new log. > This is where things go sideways. > > If I remember correctly, I've retested this as far as 16.2 and R3 but not > R4. Perhaps a fresh set of eyes would help here. I do see that I tried > putting in a 3 second delay when rolling the log in case that gave 4D > and/or the OS a chance to catch up. Didn't help. > > So, if I'm doing something foolish and wrong *please* tell me. I hate being > wrong, but I'd also rather know when I'm wrong. So, yeah, let me know. If > there's another way to approach this that's reliable, also please say. If > that way requires semaphores then, well, no....that kind of defeats the > whole purpose. At that point, I'd use non-preemptive code with NTK IPC > channels. That's been working flawlessly for years. > > One thing: Any solution has to be 100% reliable. For server-side code like > this, a success rate of 99.9% isn't even close. When an error can bring the > server down, it's a non-starter. Particularly an error that's super easy to > generate. > > The truth is that I'd really like to use disk files for logs. They're > simple, lightweight, cheap and robust. You can feed them into your > aggregator of choice in a million different ways, they take up no room in > the database, you can resume posting of entries after a crash, they're just > a solid choice. Hence, their near-universal popularity. > > P.S. I know that using CALL WORKER inevitably means some log entries will > be lost during restart. That's an acceptable cost in this particular case. > Crashing/freezing the server is not. > ********************************************************************** > 4D Internet Users Group (4D iNUG) > FAQ: http://lists.4d.com/faqnug.html > Archive: http://lists.4d.com/archives.html > Options: http://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: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
