Call worker on Client

Hi,

I can’t seem to find any relevant documentation about ‘call worker’ method behaviour when executed via client. I had an assumption that all call worker calls would end up being executed on server, but this is not the case.

Can someone please advice, what is the expected ‘call worker’ behaviour when executed from client.

By the way ‘execute on server’ doesn’t seem to work with ‘call worker’ as procedure/method parameter. So our only options to making sure ‘call worker’ adds an event to worker on server (even when executed on client) is to make ALL methods that call ‘call worker’ run on server (via method properties), or create some sort of generic method (with execute on server property) ->

This is hacky, since 4d doesn’t allow dynamic parameters

‘utils_callWorkerOnServer’ (make sure property is set of execute on server) ->

$tWorkerName:=$1
$tWorkerMethod:=$2
$cParameters:=$3

Case of
: ($cParameters.length<1)
CALL WORKER($tWorkerName;$tWorkerMethod)
: ($cParameters.length<2)
CALL WORKER($tWorkerName;$tWorkerMethod;$cParameters[0])
: ($cParameters.length<3)
CALL WORKER($tWorkerName;$tWorkerMethod;$cParameters[0];$cParameters[1])
: ($cParameters.length<4)
CALL WORKER($tWorkerName;$tWorkerMethod;$cParameters[0];$cParameters[1];$cParameters[2])
: ($cParameters.length<5)
CALL WORKER($tWorkerName;$tWorkerMethod;$cParameters[0];$cParameters[1];$cParameters[2];$cParameters[3])

	  /// etc... : (

end case

Please advise if there is simpler solution, and what the expected behaviour is when ‘call worker’ is called from client (and why wouldn’t it automatically launch on server)

Cheers,

Andrei

what is your definition of a worker?

because it seems like you have a very different view of what a worker
is.

: Andrei EVGUENOV

Please advise if there is simpler solution, and what the expected
behaviour is when ‘call worker’ is called from client (and why
wouldn’t it automatically launch on server)

but I think I speak for all 4D developers,
why would you expect a worker to launch anywhere other than the client?

a worker is a specific type of process.

if you call New process, you expect a new process to be created on the same client.

so we expect the same for CALL WORKER.

https://doc.4d.com/4Dv17/4D/17.4/About-workers.300-4883027.en.html

Sorry, I was confused about how client can interact with workers on server, and looks like the question I’ve raised was not very well structure.

We mainly use workers on server (as event queue), one use case is logging to file (a worker process on server would hold a file open and anytime we want to log large amount of data, we just raise an event with that worker, which doesn’t block the process that wants to send information to file log). Most of the time calling a worker has been done by the server, but looks like we overlooked that this sort of logging will be requested in client environment.

Anyways looks like there are a couple of ways to solve our issue, but it would be nice to have a method that can be called form a client (with dynamic variables, like some of the inbuilt 4D procedures) that would ask to execute method in the context of server worker.

Andrei,

I’ve gone round with this question too - how to get client data to the server to be logged. Lot’s of folks are forceful in their opinion that logs should only be written to disk. But the most effective way to get lots of small packets of discrete data to the server is via records. Maybe you incorporate both?

I look at log data for a lot of different purposes. Crash analysis is one end of the spectrum. At the other end are client behaviors, specific method usage, other interesting items - activity, if you will. And things interesting during development.

If a database is fairly small you can combine all those logs into a single one. Especially if it’s single user. If it’s large you start getting into the sort of problems you detail. I split these out now. Clients and the server maintain a more detailed log that’s written to disk in a manner like you describe. I also include a log table I write information about user behavior too. I include most errors but they get written to the client log first. Because this table can get quickly get large I run a housekeeping stored method to write records to disk on the server after some period of time. Usually a couple of weeks. I can always re-load the data if I need to.

I like being able to look at the activity log in real time across all users. This is a great way to spot errors before users complain about them. Or spot errors that users simply roll over without mentioning but get annoyed over. The client log on disk is more forensic.

If you truly need to keep all these client logs on the server you could include a small routine on Client Startup to send the most recent one to the server for storage on disk there. Or you could have the server periodically collect them from the clients using EXECUTE ON CLIENT.

This doesn’t give you the up-to-the-millisecond record of client activity available through the server. If you want that you would be looking at the 4D log options anyway.

Just some thoughts on breaking up the logging task.

if the field type is text or object, and “store record outside data file” is enabled, you kind of get a composite solution.

by the way, object fields are stores in UTF-8, which saves space compare to text which are stored in UTF-16.

also the preferred way to deal with “dynamic” (variable type/count) parameters is to use object properties.