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 _______________________________________________ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
