How do workers die?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

How do workers die?

4D Tech mailing list
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: How do workers die?

4D Tech mailing list
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 <[hidden email]> 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
[hidden email]



**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: How do workers die?

4D Tech mailing list
In reply to this post by 4D Tech mailing list
On Oct 5, 2017, at 11:06 PM, David Adams via 4D_Tech <[hidden email]> 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
[hidden email]





**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: How do workers die?

4D Tech mailing list
In reply to this post by 4D Tech mailing list
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: How do workers die?

4D Tech mailing list
In reply to this post by 4D Tech mailing list
>
> 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:[hidden email]
**********************************************************************