4d server hangs while curl command executes by LEP

I kindly ask the community for a suggestion about a problem we are having on a 4D server 16R6 32 bit on Macs: we have a server method that use LEP to call a curl command in a loop that do a complex job in an external system.
This curl command has to run synchronous, because we need answer to continue in the loop.
All runs correctly, the problem is that this curl command takes some seconds to complete and 4d server seems hanged while waiting and all connected users are noticing slow execution in their regular use.
Once curl command get finished, users speed returns normal.
We checked using activity monitor and we notice 4d server getting to 90% of CPU.
Is it a 4D bug ?
Why so many resource is taken by 4d server while LEP is running ?
4d server is just waiting, cannot understand what’s doing ?
What can be done ?
I know that one idea will be to dedicate a 4d client on doing that job, but it sound not like a good idea.
Using the Miyako curl plugin can make things better?
Or need to jump to 4D server 64 bit for some preemptive use ?
Thanks…

if you run curl from the console you will see that it is designed to print its activity in real time,
either as a table showing percentages or a “progress bar” of #####.

4D is not just waiting for curl to finish,
it is listening to stdOut and stdErr to which curl is constantly feeding information.

you could reduce the amount of feedback with the -# option,
or use v16 in compiled-preemtive mode (desktop or server),
but the fundamental issue does not change,
which is that curl is simply not made for long synchronous call via LEP.

the plugins use libcurl which is the engine part of curl,
so instead of waiting you get callbacks during operation.

https://github.com/miyako/4d-plugin-curl-http
https://github.com/miyako/4d-plugin-curl-ftp

Another option might be to run the curl operation from a 4D Remote connection if possible. That way the other server connections would not be affected.

Thanks for the reply.
Hello tried the LEP curl with -# option, but I don’t see big improvement, just tried now as new possibility to dump the LEP curl result to a file instead of stdOut to see it better or not (I wait for some users feedback)…do you think it could bring better result than stdOut ?
I was also thinking to delegate a client machine on doing this LEP curl stuff, by doing EXECUTE ON CLIENT, this is for sure the best option in term of reducing 4d server resources.
What sound not very exciting (I have no idea what else to do) is how to call a client method in synchronous mode and get immediate result (as greatly do the EOS method attribute). Using EXECUTE ON CLIENT is great, but it is asynchronous and execution is queued, it sound not so exciting on having to build some interprocess mechanisms as waiting until client job is finished.
If it exists the possibility (seems for sure an historical 4D missing functionality) to execute a client method and get immediate result it will be the perfect point, opening many new options as solution to many cases.
Thanks anyway for the suggestions given.

you could launch curl in asynchronous mode (output to file),
and keep an eye on the PID returned in $5.
you can do that on the server side.

clients don’t have preemptive mode,
so your other idea would block the client.

consuming stdOut and stdErr is expensive for 4D.
for something like curl, it’s not a good idea to call it in synchronous mode.
whether on the client or the server.

Sorry what command are you meaning for $5 parameter to look for PID ?
Thanks for the help.

LAUNCH EXTERNAL PROCESS now returns the ID of the launched process.

http://doc.4d.com/4Dv16/4D/16.3/LAUNCH-EXTERNAL-PROCESS.301-3652461.en.html

Thanks Keisuke, we’ll give a try.

Hello

problem seems solved: 4D server loading seems now lots reduced for connected users while curl shell command is running

Thanks for the help given.