Hello esb-devs, Asankha, are you back from travelling? I just like to query the status of graceful cluster restart. I have seen the progress of your preparation on the synapse core part. Fine! When do you think you will have something ready for testing?
Maybe it would be possible to bundle this with the Hessian fixes? Or do you need more time on this? While reading Indikas comment to https://wso2.org/jira/browse/ESBJAVA-439 I was asking myself why there is no point to configure all members of a cluster so that every node would be automatically aware of the cluster members (something like cluster.conf or preferably an additional (optional) element in synapse.xml)? What do you think? Having this configuration information available would be a kind of prerequisite for any kind of ESBClusterManager implementation and also useful for other clusterwide features. I also thought about how to best integrate the cluster restart feature into the current esb environment. How do you plan to do this? >From a users perspective I think it would be best to have two options: a) command line b) admin/monitoring console a) Ideally this would be just another option to the shell script wso2-esb-deamon.sh like start, stop, or restart (e.g. restart-cluster). By the way for convenience I created a symbolic link with name esbctl for that shell script which proved to be nice to use. b) Of course this has lower priority. It would be nice to have some kind of administration/monitoring webapp to browse the cluster definition (see each member with its current status), where you are able to execute some actions on either the cluster or a single instance as appropriate (start, stop, threaddump etc.). Via this console you could also expose other JMX-functionalities for monitoring purposes and thus eliminating the need to use external JMX-based monitoring solutions for some of your customers. Of course anyone is still free to implement some custom JMX-based monitoring, but an out of the box solutions is always impressing. Also statistics and logging information would be interesting. Everything besides the actual configuration, as no one of an operational team should be allowed and able to change a live configuration. This is the reason I can't imagine to make the current esb management console available in production. Did you already discussed to split the Management console into two parts? - Configuration Console - Administration and Monitoring Console Finding the right naming here is quite difficult. Basically I think of the idea to separate the configuration (endpoints, proxies, sequences, task etc.) from administration (setting ports, pool-sizes, or restarting instances) and monitoring (proxy usage statistics, log analysis, health checking, queue size monitoring etc.) of esb instances/cluster. Regards, Eric _______________________________________________ Esb-java-dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
