On Tue, Feb 21, 2012 at 2:43 PM, Denis Weerasiri <[email protected]> wrote:
> > > On Tue, Feb 21, 2012 at 11:04 AM, Nirmal Fernando <[email protected]> wrote: > >> >> >> On Tue, Feb 21, 2012 at 10:18 AM, Nirmal Fernando <[email protected]>wrote: >> >>> 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: >>> >>> Value of the path attribute should change like this: >> >> >>> <domain name="wso2.as.domain"> >>> <instance name="wso2as-4.1.0-SNAPSHOT" >>> path="/home/nirmal/Desktop/wso2as-4.1.0-SNAPSHOT/bin/wso2server.sh"/> >>> <instance name="wso2as-4.1.0-SNAPSHOT" >>> path="/home/nirmal/Temp/wso2as-4.1.0-SNAPSHOT/bin/wso2server.sh"/> >>> >>> ..... >>> </domain> >>> <domain name="wso2.bps.domain"> >>> <instance name="wso2bps-4.1.0-SNAPSHOT" >>> path="/home/nirmal/Desktop/wso2bps-4.1.0-SNAPSHOT/bin/wso2server.sh"/> >>> <instance name="wso2bps-4.1.0-SNAPSHOT" >>> path="/home/nirmal/Temp/wso2bps-4.1.0-SNAPSHOT/bin/wso2server.sh"/> >> >> Aren't these name attribute in <instance/>, redundant in your auto > scalar scenario? > Whoops yes! We can get rid of that. >>> ..... >>> </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 < >>> [email protected]> wrote: >>> >>>> On Mon, Feb 20, 2012 at 8:17 PM, Nirmal Fernando <[email protected]> >>>> wrote: >>>> > 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. >>>> >>>> +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/ >>> >> >> >> >> -- >> >> 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 >> >> > > > -- > Thanks, > Denis > ---------------------------------------------------------- > *Denis Weerasiri* > Software Engineer > Integration Technologies Team, WSO2 Inc.; http://wso2.com, > *email: denis <http://goog_277208233/>** [AT] wso2.com <http://wso2.com/>* > *phone: +94117639629 > * > *site: > **https://sites.google.com/site/ddweerasiri/*<https://sites.google.com/site/ddweerasiri/> > *blog: **http://ddweerasiri.blogspot.com*<http://ddweerasiri.blogspot.com/> > * > twitter: **http://twitter.com/ddweerasiri*<http://twitter.com/ddweerasiri> > * > linked-in: > **http://lk.linkedin.com/in/ddweerasiri*<http://lk.linkedin.com/in/ddweerasiri> > > > _______________________________________________ > Carbon-dev mailing list > [email protected] > http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > > -- 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
