Re: How do workers die?
> > Perhaps I am misunderstanding your question. Do you mean after a worker > has been killed with KILL WORKER? > Clearly, I asked my question poorly as you and Julio both found my question unclear in the same way. (Or perhaps it's just that it's unclear to people who can speak Portuguese?) In any case, yes, I mean when a worker has been killed explicitly. I've tested out workers extensively - I've spent months on CALL WORKER, etc. and drafted a few hundred pages about them. None of that will ever see the light of day, but I've spent a fair amount of time studying them. I'm now trying to put them into production, working with the limitations they have based on the design choices that were made for this part of 4D. And bugs. The way I like to kill workers is to have a method that does it that is called from *within* the worker. This allows for a more organized shutdown. Closing files, etc. You can call the worker to execute the method in the context of the worker very easily. Tip: It's also easy to forbid method to run outside of the context of a worker with a specific name. If (Current process name # "YourWorkerNameHere") // Deal with the illegal call. Else // Do your thing End if That's a solution to a problem not everyone will run into, but it's a tidy little trick when it is appropriate. ** 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 **
Re: How do workers die?
Julio, Thanks for taking a stab at it. I should have been more clear, I mean when workers are killed. I do this from within the worker to try and have an orderly shutdown. Your reading of the docs is correct though. Workers are a thread of execution, like any other process, but 4D has its own magic loop waiting for incoming 'messages'. These messages aren't really messages, they're blocks of code that are appended to the worker's thread of execution and then run through EXECUTE. At least, that's how they behave. ** 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 **
Re: How do workers die?
On Oct 5, 2017, at 11:06 PM, David Adams via 4D_Tech <4d_tech@lists.4d.com> wrote: > > * New process () / Execute on server () When they finish, they're dead. > They're supposed to release file locks, record locks, etc. If you start a > new copy of the process with the same name, it starts off in a "virginal" > state. > > Which is it for workers? I thought it was like New process(), but am seeing > evidence that it's not always the case. The docs aren't explicit. I take > the implication to be that they should be fully dead, even if started > almost instantly. But this doesn't seem to be true. Perhaps I am misunderstanding your question. Do you mean after a worker has been killed with KILL WORKER? Workers are not like New Process/EXECUTE ON SERVER processes in that they do not die "When they finish...". To me that is the whole idea of workers. If you are asking with respect to your other issue with file locks, I hear you. I have not tested the problem, but if files. or anything else, are remaining locked after a worker is killed with KILL WORKER then indeed Houston We Have a Problem. With respect to locked files, killing a worker should have the same effect on any files locked by the worker as one would see if you restarted 4D. My guess is, unfortunately, that the unlocking files when 4D quits is managed by the OS not 4D as is would be the case with workers. John John Baughman Kailua, Hawaii (808) 262-0328 john...@hawaii.rr.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 **
Re: How do workers die?
Well, documentation says Workers don’t die. You have to kill them, or quit 4D. From 4D 16.2 Docs, About Workers page: "Unlike the New process command, a worker process remains alive after the execution of the process method ends.” Web process stay dormant for awhile and then die if no new request arrives. If you use 4D’s session management, the Web processes retain their Session ID, and are reused only for new requests with the same Session ID cookie. New process() die when their method ends, so if you want to keep them alive as a daemon, you have to loop forever with a Delay Process() at some point. Nothing new there with latest versions. That’s my understanding from the docs. I have not used Workers yet, so cannot confirm the docs. cheers, julio > On Oct 6, 2017, at 6:06 AM, David Adams via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > Does anyone know or can they find out the following? > > What happens when workers die? 4D has at least two different approaches to > this: > > * HTTP processes wait before dying, but then die if there are no new > requests after some time. (Or at least they used to.) Meaning, an HTTP > process may or may not have old variables and so forth in place. > > * New process () / Execute on server () When they finish, they're dead. > They're supposed to release file locks, record locks, etc. If you start a > new copy of the process with the same name, it starts off in a "virginal" > state. > > Which is it for workers? I thought it was like New process(), but am seeing > evidence that it's not always the case. The docs aren't explicit. I take > the implication to be that they should be fully dead, even if started > almost instantly. But this doesn't seem to be true. > > The difference is pretty important. > > Is there a way to find out authoritatively? I've sent it to Wayne for tech > support, so maybe that will work in time...but perhaps someone knows or has > a shortcut to finding out? -- Julio Carneiro jjfo...@gmail.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 **
How do workers die?
Does anyone know or can they find out the following? What happens when workers die? 4D has at least two different approaches to this: * HTTP processes wait before dying, but then die if there are no new requests after some time. (Or at least they used to.) Meaning, an HTTP process may or may not have old variables and so forth in place. * New process () / Execute on server () When they finish, they're dead. They're supposed to release file locks, record locks, etc. If you start a new copy of the process with the same name, it starts off in a "virginal" state. Which is it for workers? I thought it was like New process(), but am seeing evidence that it's not always the case. The docs aren't explicit. I take the implication to be that they should be fully dead, even if started almost instantly. But this doesn't seem to be true. The difference is pretty important. Is there a way to find out authoritatively? I've sent it to Wayne for tech support, so maybe that will work in time...but perhaps someone knows or has a shortcut to finding out? ** 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 **
