Thanks Reuben,
1.
On each (large) server we have about 1k (at least) such processes with a short ON IDLE, and the stats on the server are OK.
Is there anything on GPAAS that I need to monitor to see if anything is of concern?
2.
The use case (I hope) is that a user, for example, uses the GDC to operate our 4GL application (enter initial data), then switches over to a native Windows application (further data processing), not using GDC for a few minutes (maybe they have 2 monitors, and they move their mouse away from the GDC app to the other Windows app).
So, having an ON IDLE in the GDC (usually with no GUI changes) allows the backend to decide if work is required (which it is not, most of the time), and in the rare cases where it is (every few minutes, not every 3 seconds), then frontend calls (such as file transfers) take place between the GDC backend and the user's frontend PC.
If the ON IDLE handler decided that some front-end call had to be made, then some UI changes will be made (update the status bar for example).
In case the ON IDLE decides that a bigger UI change is needed, we have global variables that indicate if the user in the middle of an operation (in the middle of an INPUT, some data not saved...), in which case the planned "big" GUI operation is not performed.
3.
A GDC / GBC notificationpushed event handler for GUI applications sounds interesting: I will read up the GMC docs on this.
4.
I was looking at event busses and their components (at various levels, Azure Service Bus, Google Pub / Sub, Kafka, RabbitMQ, ...), but, for my current project, they are all too heavy for an initial proof of concept. I might come back to these for a later production quality solution, more investigation will be required.
I am now looking at web sockets, that would maintain a bidirectional link between a remote web API / microservice.
Does Genero have support for the ws:// protocol (web sockets)?
I am investigating if it would be possible for Genero 4.01 headless daemon (not a GUI application) to make a web API call (REST), such as subscribing to a topic of interest, then have the daemon sleep using a blocking select call on the web socket, waiting for the remote microservice to have (very small) messages ready to be read with another REST call.
Is there any well established Genero "event bus" programming pattern or strategy for such a daemon? Are people usually polling the remote microservice?
As my time with this initial investigation is almost up, I have taken some notes related to any Genero solution, and then moved on to code my ideas in Google Go, but this is intended to be throwaway code.
Thanks again for your detailed and prompt responses.
Regards,