Hi All, I need your views on following.
In the Agent side we need to have a configuration file (say instances_config.xml) which specifies the paths and names of the instances belong to domains. I thought to have following structure: <domain name="wso2.as.domain"> <instance name="wso2as-4.1.0-SNAPSHOT" path="/home/nirmal/Desktop/wso2as-4.1.0-SNAPSHOT"/> <instance name="wso2as-4.1.0-SNAPSHOT" path="/home/nirmal/Temp/wso2as-4.1.0-SNAPSHOT"/> ..... </domain> <domain name="wso2.bps.domain"> <instance name="wso2bps-4.1.0-SNAPSHOT" path="/home/nirmal/Desktop/wso2bps-4.1.0-SNAPSHOT"/> <instance name="wso2bps-4.1.0-SNAPSHOT" path="/home/nirmal/Temp/wso2bps-4.1.0-SNAPSHOT"/> ..... </domain> ..... WDYT? PS: It is my understanding that the autoscaler component passes the 'domain name' to the "Autoscaler Service", when it wants to scale. On Mon, Feb 20, 2012 at 9:31 PM, Selvaratnam Uthaiyashankar < shan...@wso2.com> wrote: > On Mon, Feb 20, 2012 at 8:17 PM, Nirmal Fernando <nir...@wso2.com> wrote: > > Hi Shankar, > > > > On Mon, Feb 20, 2012 at 5:34 PM, Selvaratnam Uthaiyashankar > > <shan...@wso2.com> wrote: > >> > >> Hi Nirmal, > >> > >> Good progress!. we can do a review on the work already done. > > > > > > Thanks, will arrange a review this week. > > > >> > >> > >> Did you try the agent in windows? > > > > > > No, I didn't! > > > >> > >> Is it using any native code? > > > > > > It needs to use native code in cases like spawning a new JVM (in Ubuntu > we > > need /bin/sh to run the script 'wso2server.sh' in windows we need to run > the > > batch file. > > But I believe this can be handled within the code it self by checking > the OS > > name and execute appropriate commands! > > > >> > >> > >> See some comments below. > >> > >> On Sat, Feb 18, 2012 at 11:10 PM, Nirmal Fernando <nir...@wso2.com> > wrote: > >> > Hi All, > >> > > >> > I've started to implement 'new autoscaler architecture' [1] on > February > >> > 8th. > >> > After having a discussion with Azeez, we came up with three milestones > >> > for > >> > the first iteration. > >> > > >> > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > >> > > >> > M1: Make a WS call spawns a new JVM instance & make the new instance > >> > joins > >> > the cluster with hard coded Agents. > >> > > >> > M2: Finish Agent registration related parts and spawn a new instance > in > >> > a > >> > selected Agent. > >> > > >> > M3: Let current autoscaler component calls 'AutoscalerService' and > >> > spawns a > >> > new JVM instance in a selected Agent. Also applying WS security. > >> > > >> > > >> > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > >> > > >> > I've attached set of images which depicts different stages of new > >> > architecture. Reading order of images is as follows: > >> > > >> > agent-reg --> autoscaler --> spawn --> cluster > >> > > >> > > >> > M1 is already finished. > >> > > >> > I've almost done the Agent registration (M2) aspect. > >> > > >> > What it does now? > >> > > >> > AgentManagementService and AutoscalerService should be deployed in the > >> > back-end server. (say: IP is 192.168.1.2) > >> > > >> > AgentService should be deployed in machines (i.e. where new JVM > >> > instances > >> > will be spawned). (say: IP is 192.168.1.3) > >> > > >> > AgentService do a web service call (eg: curl -X GET > >> > http://localhost:8080/axis2/services/AgentService/agent) to > >> > AgentManagementService and get registered. Then AgentManagementService > >> > stores the URL (eg: > >> > http://192.168.1.3:8080/axis2/services/AgentService/) of > >> > that particular request. > >> > > >> > When autoscaler API (implementing this is M3) wanted to spawn a new > >> > instance > >> > (JVM or EC2 or anything else), it should call AutoscalerService (eg: > >> > curl > >> > --data "instanceName=as" -X POST > >> > http://192.168.1.2:8080/axis2/services/AutoscalerService/instance). > Then > >> > AutoscalerService decides which kind of instance to spawn. > >> > > >> > If AutoscalerService decides to spawn a JVM instance, it creates a new > >> > JVMAdaptor instance. JVMAdaptor then calls (eg: curl -X GET > >> > http://192.168.1.2:8080/axis2/services/AgentManagementService/agent) > >> > AgentManagementService in order to pick an Agent. > AgentManagementService > >> > picks an Agent in a round robin manner and sends back that Agent's EPR > >> > (http://192.168.1.3:8080/axis2/services/AgentService/) to JVMAdaptor. > >> > Then > >> > JVMAdaptor does a web service call to that particular AgentService and > >> > asked > >> > it to spawn the requested instance (instance is yet hard coded). > >> > > >> > Spawned instance then joins the cluster. > >> > > >> > > >> > Current observations: > >> > > >> > Currently starting instance aspect is done. > >> > > >> > I've tested this using 2 machines, and starting instance works fine. > >> > > >> > It is observed that the spawned JVM instances get killed when you > issue > >> > 'ctrl+c' in the terminal where axis2 running. But when I killed > >> > axis2server.sh process only, the new JAVA process wasn't get killed. > To > >> > avoid process get killing when issue ctrl+c, we might need to handle > >> > SIGINT > >> > [2]. Can't we be happy with the fact that it doesn't get killed after > >> > killing axis2server.sh? > >> > >> JVMs (which were created) should live even if you kill the agent. > >> > > > > Yes, but the problem is how you kill! If you use kill -9 and kills Axis2 > > related process (Axis2 is where Agent Service is deployed), spawned JVM > > instances aren't get killed. > > Anyway will research a bit more, I understand that spawned instance > should > > never get killed, unless it is asked to! > > > >> > >> > > >> > > >> > Work to be done: > >> > > >> > Terminating and finding instance aspects should be addressed. > >> > >> You have to keep track of which JVMs/VMs created by the autoscaler. > >> Otherwise you will not be able to stop them when you want to scale > >> down. I believe, this information should be stored/kept with > >> "autoscaler service". > > > > > > I have started to implement this part today! According to the design > > 'Autoscaler Service' is only responsible for > > deciding the type of instance it should be spawned. That is a JVM > instance > > or an EC2 instance or something else. Thus, it keeps track of > > the type of instance spawned. > > > > It is JVM Adaptor which keeps track of instances spawned in each Agent. > > +1. It should be JVM adapter for JVM instances and EC2 adapter for EC2 > instance, etc. > > Shankar > > > > > > And it is respective Agent Service that kills an instance, upon a > request! > > > > > >> > >> > >> > The 'sad side' (when things go wrong) should be addressed. > >> > AgentServices should know EPR of AgentManagementService (this is hard > >> > coded > >> > now). Should read from a config file? > >> > >> +1 fore reading from config file. > > > > > > Great! > > > >> > >> > >> > >> > JVMAdaptor should keep a map of Agent EPR to AgentService client, to > >> > avoid > >> > creating multiple clients to access the same Agent. > >> > AgentService should keep a count of spawned instances and get itself > >> > unregistered if it can't handle any new instances (threshold value > >> > should be > >> > decided). And when it feels (another threshold) that it can handle new > >> > instances it should register again. > >> > Autoscaler API should be designed. > >> > Should port EC2 client to EC2Adaptor. > >> > Should test the whole scenario. > >> > > >> > > >> > I appreciate your comments/thoughts on above facts. > >> > > >> > > >> > [1] > >> > > http://mail.wso2.org/mailarchive/architecture/2011-October/006414.html > >> > > >> > [2] http://www.cons.org/cracauer/sigint.html > >> > > >> > > >> > > >> > -- > >> > > >> > Thanks & regards, > >> > Nirmal > >> > > >> > Software Engineer- Platform Technologies Team, WSO2 Inc. > >> > Mobile: +94715779733 > >> > Blog: http://nirmalfdo.blogspot.com/ > >> > >> > >> > >> -- > >> S.Uthaiyashankar > >> Senior Architect & Senior Manager > >> WSO2 Inc. > >> http://wso2.com/ - "lean . enterprise . middleware" > >> > >> Phone: +94 714897591 > > > > > > > > > > -- > > > > Thanks & regards, > > Nirmal > > > > Software Engineer- Platform Technologies Team, WSO2 Inc. > > Mobile: +94715779733 > > Blog: http://nirmalfdo.blogspot.com/ > > > > -- > S.Uthaiyashankar > Senior Architect & Senior Manager > WSO2 Inc. > http://wso2.com/ - "lean . enterprise . middleware" > > Phone: +94 714897591 > -- Thanks & regards, Nirmal Software Engineer- Platform Technologies Team, WSO2 Inc. Mobile: +94715779733 Blog: http://nirmalfdo.blogspot.com/
_______________________________________________ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
