Wojciech, you started doing something in this area. Please update the task with progress. If this is still not completed, please push it for next version.

Wojciech, what is the status of this task? Please consult with Andrzej as he has done some work on this. Please list all commands which work correctly in a cluster mode and a list of commands which require some work.

As indicated in the ticked body - this task was about creating solution which would allow seamless execution of commands without any need to adjust those.

With that in mind should I proceed with creating list of commands still needing manual adjustments? Andrzej worked recently on #3375.

Yes, create a list of all commands that need adjustments.

I do not think it is possible to invent a general solution which would work for all possible cases unless you work on most of possible cases and understand all of them well. While you and possibly Andrzej work on clustered versions of commands, think of a more general approach and solution which would handle clustering use-case in more or less transparent way.

Artur Hefczyc wrote:

Yes, create a list of all commands that need adjustments.

Following list is list of commands that (in my opinion) could/should be clustered. Others (Adding user) makes no sense to execute on all nodes.

src/main/groovy/tigase/admin/AddUserTracker.groovy

src/main/groovy/tigase/admin/CompManager.groovy -- possibly -- unified component management within whole cluster

src/main/groovy/tigase/admin/CompRepoReload.groovy -- possibly

src/main/groovy/tigase/admin/ConnectionTime.groovy -- not sure it it makes sense

src/main/groovy/tigase/admin/GetListOfActiveUsers.groovy

src/main/groovy/tigase/admin/GetListOfIdleUsers.groovy

src/main/groovy/tigase/admin/GetListOfOnlineUsers.groovy

src/main/groovy/tigase/admin/GetNumberOfActiveUsers.groovy

src/main/groovy/tigase/admin/GetNumberOfIdleUsers.groovy

src/main/groovy/tigase/admin/GetRegisteredUserList.groovy

src/main/groovy/tigase/admin/GetTopActiveUsers.groovy

src/main/groovy/tigase/admin/PluginManager.groovy -- unified pluginmanagement within whole cluster

src/main/groovy/tigase/admin/RemoveUserTracker.groovy

src/main/groovy/tigase/admin/S2SBadConnectionStates.groovy

src/main/groovy/tigase/admin/S2SResetBadConnections.groovy

src/main/groovy/tigase/admin/UserRosterManagement.groovy

src/main/groovy/tigase/admin/UserStatistics.groovy

I do not think it is possible to invent a general solution which would work for all possible cases unless you work on most of possible cases and understand all of them well. While you and possibly Andrzej work on clustered versions of commands, think of a more general approach and solution which would handle clustering use-case in more or less transparent way.

Well, solution that would cover all cases would be difficult, but in principle doing what we are doing now in groovy scripts but at the level of BasicComponent (i.e. stamping command to execute locally + forward to other node and if it was forwarded only execute locally) should work just fine). Thing to consider is that no all commands should be treated like that - for example those to Add/Remove user.

One problem with approach of: "execute locally + forward to other nodes" is that, some of the commands return results which should be displayed to the user executing the command. A correct solution should display combined results from all cluster nodes in a single window.

So actually, as far as I can see, we have following different use-cases:

1. A command is executed only on 1 cluster node (because it does not make sense to execute it on all nodes), for example: "add user", "change user password", and possibly some others

2. Commands that have to be executed on all cluster nodes but we do not need execution results from all nodes, just a confirmation from the first cluster nodes: "remove user", "reload repo", "add user tracker", "remove user tracker", etc....

3. Commands which are executed on all cluster nodes which have to display execution results from all cluster nodes combined in one window

I think that for this kind of 3 use-cases we could prepare some API to make it easier to code such commands. What do you think? %wojtek , %andrzej.wojcik

It's a big work, we have to postpone it for future version.