Is there a way to restart a batch-process-job from within an NG-client? It would be ideal, if there is an API for accessing the Servoy-Admin-Page.
Background: we use batch process for various jobs. Usually they work fine, but from time to time they hang up and stop. We’d like to give a (power-)user an easy way to check, if the batch processes are still running and if not to restart again (without to go on the Servoy-Admin-Page). I know about the “plugins.UserManager.getBatchProcessors()”-function. With that I get a list of batch-processes, but I can’t do anything with that (not stop or start).
Thanks in advance for any suggestions.
Best, Roland
The batch processor is no more than a headless client.
You can spawn a headless client using the headless client plugin
By using the client manager plugin, you can get all connected clients, their types and you will have the possibility to shutdown a particular client.
Concerning the UserManager plugin, this plugin is no longer supported. (direct information from the developer)
This means that the plugin can no longer be used in Servoy versions 2022.9 and higher, without modifying the jar file yourself.
Future Servoy version might even break the plugin as the ServoyAPI might change.
But this is not what I’m looking for. The problem is, that in some circumstances the batch process will be shut down (status “not running” in Servoy-Admin-Console) and so the client is not there anymore and in consequence the client manager can’t deliver it. And if I want to restart it, I have to know all the starting arguments that are stored on the “batch process” (solutionname, username, password, starting arguments). These are informations I’ll never get from the client manager.
Maybe there’s another solution?
Best, Roland
… and yes, I’ve heard that the UserManager-Plugin is not supported anymore. So I’m still hoping that Servoy will deliver an alternative for it in the future (I’ve heard rumours that there could come something like an API to access the whole stuff in the Servoy-Admin-Console). Hope dies last
i think it is also a good thing to look why batch processors are suddenly not running… are the exceptions?
Also what you could do is having 1 batch processor running, which just spawn the other “batch” processors as headless clients (under unique names)
and those can be checked then by something (a batch or another headless)
Edit: are you sure they are not running anymore? and then i don’t mean check the status, but if you would do some output when the batch does something are those stopping?
i think it is also a good thing to look why batch processors are suddenly not running… are the exceptions?
Yes, of course. This would always be the best solution! And we are working on that. But sometimes it’s not so easy to locate the problem and specially not in headless clients.
For example one problem we have is a batch process that calls a webservice periodically. As soon as we have a connection issue (network problem) the webservice call of course doesn’t work anymore. But it also doesn’t recover, even if the network issue is solved. We then have to shutdown the client and start it again (so in this specific situation, the solution from Marc would work because the headless client is still running but doesn’t work anymore as expected, but still has the downside that I have to know all the startup arguments for the client).
In another case (also a webservice that is called periodically) the client is gone completely. In that case we don’t have any trace so far.
Because this all is not happend so often but only from time to time (maybe once a week or so) and so far we couldn’t reproduce it, it’s quite hard to fix something.
I have found that it’s easier to implement some sort of a job management feature than relying only on Batch Processors.
The way I did it was to have a table to store the jobs (function to be called, recurrence, credentials, etc) and another table to store each run of the job (start, end, duration, result) in that way I can also troubleshoot what could be happening by adding log messages to the result.
Your power user then can create/start/stop/monitor/troubleshoot those jobs.
One client needs to be responsible for starting them all (a single batch processor as Johan said) or a post import hook.
I think Patrick Rushert has a similar implementation too.
Re calling web-service, we have had similar problems with batch processors falling over every few weeks.
The code was old having run for 10+ years and needed a refresh;
Changes I made:
Set a timeout setTimeOut(number) so the http client gives up after a while.
Always check the response before trying to process looking whether response.getException() is blank.
close the http client after use to free up memory.