Add, Thanks a lot for chiming in! It's always good to hear from you guys in the US office.
I'm not sure what problem your solution is solving. I'm not trying to be flip, I just want to make sure to focus on the meat of the issue. A really common approach to log writing is as follows: Have one process manage the log disk file. So. when that thread starts, it opens the file, keeps it open, writes to it and can then close it neatly. You can then have any number of other processes message the "writer" to stream information to the disk file. Lots of OS-level files, Web servers, etc. follow this model. Why? Because it is *substantially* faster and easier than anything else. You completely sidestep race conditions on the file lock - there's no chance of a race condition because only one process *ever* opens the file. It's a nice, tidy solution. That's what I wanted to do with 4D's worker when I first saw them - I assumed that would be pretty much anyone's impression because it's such a classic use for a message+worker setup. I was excited because with a preemptive worker, you could push all of this low-value logging over onto a secondary core. It's a satisfyingly complete, tidy, and naturally low-conflict, high-performance solution. That doesn't work in 4D. Unfortunately, this doesn't seem to work. I can easily generate race conditions from opening and close the file and restarting the worker. This should be *impossible*. Something is wrong in how 4D is managing file locks. I don't know what. I start a worker, open a file, write to it, close the file, kill the worker. The file should be closed. Period. Usually it is, sometimes it isn't. I have no explanation for this, but it definitively blows up any plan to use workers for logging via a preemptive process. John Baughman in his tests thinks that the problem is flooding the worker and blowing up 4D's via memory exception. Could be. I briefly did a bit of load testing like that, but not a lot. So, either way, it doesn't look like 4D's CALL WORKER and worker system is designed to scale or work safely/reliably under heavy load. I've come to suspect that it was never intended for such tasks.The lack of a pause mechanism or a way to count 'queued' entries are telling. They're very standard (universal) features of a queuing/messaging system, but 4D doesn't have them or seem to appreciate why you would need them. I've got feature requests in for this stuff from months ago. Note that if you do any kind of heavy load, you need to be able to measure the state of a queue to see if you need to spin up another one. That 4D lacks this feature (or seemingly interest in such a feature) suggests that I'm off-base to even consider 4D workers for heavy loads. Just not built for it. 4D never said that their workers were meant for heavy lifting. I think that they were designed to handle various kinds of UI-related tasks in 4D. I haven't got much interest in that (I did a bit of a publish-subscribe system that I showed at 4DMETHOD, that was fun to work through), and I'll guess that CALL WORKER and CALL FORM are just fine for that. But for what I need? I have to conclude that 4D isn't the right tool ********************************************************************** 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 **********************************************************************
