Please forgive me if I’m being dim, but isn’t a solution (maybe not the best, but a solution) to maintain the log as records in a table, which is periodically emptied into a file by a process which opens, writes and closes that file, then deletes the records in the table?
It’s not an approach which I’ve tried, and you may have good reasons for rejecting it. I’m just curious to know what they are. Jeremy Jeremy Roussak j...@mac.com > On 25 Sep 2017, at 13:57, David Adams via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > 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 > ********************************************************************** ********************************************************************** 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 **********************************************************************
