I've posted about my various worker log problems here and on some other threads and even posted my sample database for review. Lately, John Baughman has really been sinking his teeth into this issue and has spent a *ton* of time working on it. Thank you John! The news is bad, but I figured I'd post it here as part of this thread. I won't say a lot, but John might want to explain his point of view. He's an optimistic person, with a cheerful nature and he likes people. Despite that, I still like him ;-)
Anyway, John took a copy of the sample database (including the correction contributed by David Porter) and tried to figure out what he could. My summary: * John is able to crash 4D just by flooding the queue. * He came up with some ideas to help manage the situation, but they involved either or semaphores or IP variables. * John also came to see (very quickly) that you need a function to report current queue size. Now, it's entirely possible that 4D never intended their CALL WORKER system to be used in a high-transaction setting. They have offered no guidance on the systems limitations and scope. I briefly tried crashing it with a message flood months back and thought that 4D preformed well. In fact, I was looking to see if it created disk scratch files, but I couldn't find any. John sounds like he's able to flood and crash the system pretty reliably, but not every time. One of my primary goals in using CALL WORKER was to avoid writing records and take some work off of core 1. There appears to be no safe and reliable way to meet those goals. This is a total bummer as even my HTTP push solution won't be safe. My next good idea is to see about pushing as much of the logging as I can onto NGNIX which will absolutely, definitely have zero problems with whatever we can throw at it. John my have more to say, but I think I'm likely done with this subject. ********************************************************************** 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] **********************************************************************
