Re: Questions about workers

[David Belote]

Thanks Chip.  That worked.

David Belote
Colorado Springs

On 10/18/16, 7:38 AM, "4D_Tech on behalf of Chip Scheide" 
<4d_tech-boun...@lists.4d.com on behalf of 4d_o...@pghrepository.org> wrote:

probably adding either:
- reduce selction([table];0)
or
- unload record([table])
would resoleve this problem

On Mon, 17 Oct 2016 21:56:07 -0600, David Belote wrote:
> 
> I did discover what I think is a Worker bug in doing these simple 
> tests.  Each time I ran these little tests, the very last record that 
> was created and then saved by the Worked is edit locked.  It can’t be 
> deleted.
**
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
**


**
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: Questions about workers

[Keisuke Miyako]

but is that not totally expected?

a worker is a process that does not die, like the good old application process.

so of course the last created record must stay locked until it gets unloaded, 
or the worker is instructed to die.

> 2016/10/18 12:56、David Belote  のメール：
>
> I did discover what I think is a Worker bug in doing these simple tests.  
> Each time I ran these little tests, the very last record that was created and 
> then saved by the Worked is edit locked.  It can’t be deleted.



宮古 啓介
セールス・エンジニア

株式会社フォーディー・ジャパン
〒150-0043
東京都渋谷区道玄坂1-10-2 渋谷THビル6F
Tel: 03-6427-8441
Fax: 03-6427-8449

keisuke.miy...@4d.com
www.4D.com/JP

**
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: Questions about workers

[Chip Scheide]

probably adding either:
- reduce selction([table];0)
or
- unload record([table])
would resoleve this problem

On Mon, 17 Oct 2016 21:56:07 -0600, David Belote wrote:
> 
> I did discover what I think is a Worker bug in doing these simple 
> tests.  Each time I ran these little tests, the very last record that 
> was created and then saved by the Worked is edit locked.  It can’t be 
> deleted.
**
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: Questions about workers

[David Belote]

I have many of the same questions you do about Workers.  I only discovered the 
new concept of Workers three days ago and am running experiments to try to 
figure them out myself.  But I can offer up the following.  

As for High Velocity:  I created an iteration loop that called a Worker.  The 
only thing that I had the Worker do was to Create a new record, store the 
iteration number + current date + current time in it and save the record.  I 
set it up for 500,000 iterations.  It took about the same time as just running 
in the same process (I didn’t exhaustively compare numbers).  It doesn’t seem 
to have the normal time lag that would occur to start up a New Process.  
Anyway, it was very fast.

I was also concerned about what would happen when a Worker was given a new 
request while it was still executing a previous request.  So I lmited the 
integration to just 20 records, but introduced a 3 second time delay.  It 
stored up those requests and executed all of them.  It did not drop any of the 
request on the floor.  I believe it executed the Worker requests in the same 
sequence of the Worker calls from my iteration loop, but I am not certain about 
that.  I now am wondering what the limit is for the number of requests to the 
Worker that can be stored up?

I did discover what I think is a Worker bug in doing these simple tests.  Each 
time I ran these little tests, the very last record that was created and then 
saved by the Worked is edit locked.  It can’t be deleted.

I hope this helps at least a little bit.

David Belote
Colorado Springs

On 10/16/16, 10:18 AM, "4D_Tech on behalf of Foucauld Perotin" 
<4d_tech-boun...@lists.4d.com on behalf of fp.lis...@teluric.com> wrote:

Hi,

I have some questions about workers. Sorry if it is obvious for some of 
you. I still don’t feel so comfortable with this new stuff. 

- May the workers be local processes? (naming them with a $, I guess)

- What about the stack size ? I see nothing about that, and I do not 
understand why. I guess the stack will have the mystery "default size", but I’m 
not sure... ;)

- I know that preemptive execution implies no interprocess variables. OK. 
But, if the preemptive aspect is not a priority for me now, can I still use 
inteprocess variables without any problem in my workers?

– Is the use of workers not for a high velocity compute section of an app, 
but for a regular part, with basic records filling and so, reasonable or not? 
with the idea to call the worker-process by the "call form" command, when 
needed). Why would I do that? Because some of my apps have a concept of several 
permanent processes with reuse of those. So, the workers would be better than 
the processes which are most of the time sleeping, then wake up, then go back 
to sleep, and so on...

Thanks for your upcoming replies! :)

-- 
Foucauld Pérotin
 
 Try again.
 Fail again. Fail better.
 
 Samuel Beckett 
**
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
**


**
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
**

Questions about workers

[Foucauld Perotin]

Hi,

I have some questions about workers. Sorry if it is obvious for some of you. I 
still don’t feel so comfortable with this new stuff. 

- May the workers be local processes? (naming them with a $, I guess)

- What about the stack size ? I see nothing about that, and I do not understand 
why. I guess the stack will have the mystery "default size", but I’m not 
sure... ;)

- I know that preemptive execution implies no interprocess variables. OK. But, 
if the preemptive aspect is not a priority for me now, can I still use 
inteprocess variables without any problem in my workers?

– Is the use of workers not for a high velocity compute section of an app, but 
for a regular part, with basic records filling and so, reasonable or not? with 
the idea to call the worker-process by the "call form" command, when needed). 
Why would I do that? Because some of my apps have a concept of several 
permanent processes with reuse of those. So, the workers would be better than 
the processes which are most of the time sleeping, then wake up, then go back 
to sleep, and so on...

Thanks for your upcoming replies! :)

-- 
Foucauld Pérotin
 
 Try again.
 Fail again. Fail better.
 
 Samuel Beckett 
**
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
**