Enhance idempiere monitor to be able to monitor server processes running on different cluster node
In addition to the RunOnlyOnIP control, enhance AdempiereServerMgr to skip adding server processes that have been added to AdempiereServerMgr instance at other cluster nodes
Note: All nodes must be configured correctly to join the same hazelcast cluster for this to work.
1. Each server job should have a unique id (serverId). Allowing a scheduler record to run concurrently at multiple node breaks this model. It is a tricky one to goes into and I wouldn't venture further into this.
2. The alternative is actually a very simple one. If you need to run a process at multiple node, just create multiple scheduler record for it.
> 1. Each server job should have a unique id (serverId). Allowing a scheduler record to run concurrently at
> multiple node breaks this model. It is a tricky one to goes into and I wouldn't venture further into this.
Sorry, don't understand, is it something introduced in this ticket?
That was the case before this ticket, and as said before one of my customers is exploiting that feature running a scheduled process in all nodes and controlling internally via queues which node executes which work.
From that point of view, this breaks that capability.
> 2. The alternative is actually a very simple one. If you need to run a process at multiple node, just create
> multiple scheduler record for it.
It's not that easy in an auto-scale environment (which is the case of my customer too) - depending on the load they start new nodes to cope with the increased demand.
The existing idempiere monitor application and server manager api is build with that assumption. For e.g getStatus(AdempiereProcessor) can't return a single status if the AdempiereProcessor can exists in multiple server node. Also, the scheduler state control at the scheduler window will have to be a lot more complicated since now you can have both started and stopped instance for that scheduler records at different server node, i.e the interface will have to show state by server node and allows you to control that by individual server node.
If support for running of a scheduler record at multiple node is an important feature to keep, I would have to revert all the changes (this and the scheduler state button ticket) as that's simply too much work for me to take on now.
I see, the restriction you mention is required for the cluster approach to work.
I think this improvement is very valuable and more commonly used than the all-servers-schedule. So, maybe is just about adding a migration note in the wiki pointing to this. Will keep it annotated.