Hi Shankar, On Mon, Feb 20, 2012 at 5:34 PM, Selvaratnam Uthaiyashankar < [email protected]> 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 <[email protected]> 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. 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/
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
