On Mon, Sep 25, 2017 at 12:04 PM, Epperlein, Lutz (agendo) via 4D_Tech < 4d_tech@lists.4d.com> 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:4d_tech-unsubscr...@lists.4d.com **********************************************************************
