Got an email from Timothy Penner yesterday pointing out that in his testing of this issue he has concluded that the crash occurs because 4D is being pushed past it’s memory limits. That is if run using the 32bit version of 4D. Tim suggested that we run the test using the 64 bit version of 4D.
Running the test using 64-bit 4D v16 R4, the test does not crash. Thanks Tim! I think this explains everything. Running with 32 bit 4D in a 64 bit OS I think we have a 4 GB memory limit which I think would be easily reached as the worker queue goes over 2.1 million calls. With 4D 64-bit I think we have a 16 TB memory limit… no problem running the test up to 100 million calls in the queue. My conclusion: 1. There is no queue limit that we know of except those dictated by memory constraints. 2. There is no bug or memory leak. 3. We still need a way to monitor the queue size especially if a worker is expected to be flooded with calls. It was interesting watching the test run to it’s end, as the test completes in a relatively short period of time, but the text file continues to build for several hours as the worker continues to consume it’s queue. John > On Oct 8, 2017, at 8:42 PM, John Baughman <[email protected]> wrote: > > >> On Oct 8, 2017, at 5:53 PM, David Adams via 4D_Tech <[email protected] >> <mailto:[email protected]>> wrote: >> >> Oh, I forgot to say earlier about John's finding of ~2.1M messages being a >> kind of breaking point...that number may not be replicable in other tests. >> You might find a different number. The payloads in my scratch database are >> quite small. For all I know, if you made the payloads 10x bigger, you would >> crash with ~210K messages. I won't be testing this myself. > > Why not test this. I added a bit of text to the log entry with the 2 million > calls set to run... > > $text:=“” No crash. Only an index number is being logged, ie, 1, 2, 3, etc. > $text:=“j”*16 No problem > $text:=“j”*32 Crashes near the end > > Here is the kicker. If I am running interpreted with the Runtime Explorer > open it crashes very early and the Runtime Explorer throws an array range > error on occasion before 4D crashes. Sometimes with $text:=“j”*32 set it > actually completes, but if I try to open the Runtime Explorer, 4D crashes. > > Now I ‘m thinking maybe it’s not the worker queue limit per say but a memory > leak associated with the worker and/or it’s queue. > > John > > > > > John Baughman > Kailua, Hawaii > (808) 262-0328 > [email protected] <mailto:[email protected]> > > > > > John Baughman Kailua, Hawaii (808) 262-0328 [email protected] ********************************************************************** 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] **********************************************************************
