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
**********************************************************************

Reply via email to