reuse hc

Classic Servoy
1

Hi,

Is there a way to reuse the same headless client from multiple other clients.
The main question is how do I get the client UUID and how do other clients get this UUID

Regards,

2

As of Servoy 6.1, the Headless Client plugin has a new function to get or create a Headless Client for an ID you can specify yourself.

Using this function, all clients can getOrCreate a HC for the ID you specify: if the HC doesn’t exist yet, a new one will be created with the given ID, otherwise a reference to the already exisiting HC will be retunred.

Paul

3

Hi Paul,

first of all thanks for the info.

Is there a way to do something simular in 5.2.15 ?
I am looking at finding out the client UUID and distribute that somehow.

I would like to retreive the client UUID ( the same that is displayed on the client information page in the servoy admin pages)

I tried :

globals.jsclient = plugins.headlessclient.createClient("test_hc", "hn","hn", hcArgs)
application.output('jscl= ' + globals.jsclient)
application.output('cl= ' + globals.jsclient.getClientID())

output is :

jscl= JSClient[AAE5FF59-2D6A-4758-AABD-3A107082761C]
cl= AAE5FF59-2D6A-4758-AABD-3A107082761C

But If I look at the servoy admin page the client uuid =

F9D7D58C-8577-437D-9205-DB70E632C342

I thought that globals.jsclient.getClientID() woould return the Client UUID.

I can not find conclusive information in the wiki.

Is this a bug or do I simply misunderstand ?

4

Hi Hans,

The ID’s returned as ClientID for a JSClient is a different value as the ID displayed on the admin page (for security purposed), so you cannot compare the two.

To achieve the same in 5.2.15 the “easiest” way would be to store the ClientID in a table on creation and in other clients read it form the table.

Paul

5

We accomplish this by having a pool of “worker” headless clients that poll a table looking for work to do.

Any client that needs a headless client to run some work writes a job to this table (methodname, arguments, priority, etc).

This alleviates the clients from having to worry about which HLC to send their work to, but you do lose the ability to naturally get the return value from whatever you are running.

6

You can also use Velocity in pool mode to manage that pool of headless workers called by web services - then the web service can return a value ;)

7

ptalbot:
You can also use Velocity in pool mode to manage that pool of headless workers called by web services - then the web service can return a value ;)

Interesting, I didn’t know Velocity had that. Is there a way to call these asynchronously? Would you still recommend this for large batches of jobs?

Asynchronously because one of our primary uses is to offload a long running process to a server and obviously waiting for a return in that case is non-optimal.

Large batches because a frequently used aspect of my system is to queue up thousands/tens-of-thousands of jobs to run on the server and be sure that even in the even of a catastrophic failure (loss of power, automatic windows update, etc) that all jobs will complete as expected.

8

Velocity has 3 headless mode:

  • application = one headless for all requests,
  • pool = a pool of headless answering requests,
  • session = one headless per HTTP session.

And this per solution.

Now, to run asynchronously from Servoy, the problem would not be too much on the Velocity side, but that you would probably use the http plugin to send a call to your web service, whether a get or a post or put request, in any case, the call to executeRequest() would be a blocking one. So I’m afraid it will not fit your bill.

9

the problem would not be too much on the Velocity side, but that you would probably use the http plugin to send a call to your web service, whether a get or a post or put request, in any case, the call to executeRequest() would be a blocking one.

And even there is Servoy working on! :wink:
https://www.servoyforge.net/projects/se … sions/8277

10

Nice!