[prev in list] [next in list] [prev in thread] [next in thread]
List: wsas-java-dev
Subject: Re: [Carbon-dev] [Stratos-dev] [Update] JVM Autoscaler
From: Nirmal Fernando <nirmal () wso2 ! com>
Date: 2012-02-29 6:16:02
Message-ID: CAJ+w7Fkx90QDQeKyMfJgdfXCr3-o9xpjXssCOVK3BOEbFXU-+Q () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Wed, Feb 29, 2012 at 11:10 AM, Dileepa Jayakody <dileepa@wso2.com> wrote:
> Hi,
>
>
> On Wed, Feb 29, 2012 at 10:57 AM, Nirmal Fernando <nirmal@wso2.com> wrote:
>
> > Hi,
> >
> > I have few other concerns to get clarified and few thoughts.
> >
> > 1. Original design was to spawn EC2 instances after the number of live
> > instances exceed a threshold value (eg: 25). What if we spawn an EC2
> > instance only if we failed to spawn a JVM instance in any Agent? As far as
> > I see, the latter may be bit inefficient but cost effective (since we're
> > not spawning an EC2 instance when we can spawn a JVM instance).
> >
> > 2. What's the standard way of specifying Agent's working directory? I
> > thought of adding it to the autoscaler_agent_config.xml. Please see [a].
> >
> > 3. How to specify the path to the "autoscaler_agent_config.xml"?
> > Currently it is hard coded.
> >
> > 4. How to let AutoscalerService know the EPR of the
> > AgentManagementService? Currently it is hard coded. Is it good to assume
> > that both autoscaler service and agent management service are hosted in one
> > location, and deriving the EPR of the AgentManagementService?
> >
> > 5. Agent should be smart enough to decide whether it can spawn a new JVM
> > instance, i.e. whether it has the minimum required memory etc. available.
> > What about using Dileepa's boot-up validator component for this purpose?
> >
> > Are you looking at total RAM or free RAM for this purpose?
>
Agent should satisfy all the minimum requirements needed for a server
start-up.
> I think OperatingSystemMXBean:
> http://www.docjar.com/docs/api/com/sun/management/OperatingSystemMXBean.htmlwould \
> be helpful to you for this requirement.
Thanks for the pointer!
>
> > [a]
> > <!--
> > This file should specify all the Agent related configuration details.
> > -->
> > <agentConfig>
> >
> > <!-- This points to the place where helper services such as
> > AgentManagementService
> > and AutoscalerService hosted. -->
> > <autoscalerHost url="http://localhost:8080/axis2/services/"/>
> >
> > <!-- Following element should points to the working directory of this
> > Agent. This is the directory
> > where Agent will copy the extratcted carbon-home directories when a
> > new instance is spawned.-->
> > <workingDir path="/home/nirmal/Documents/autoscaler/work/"/>
> >
> > <!--
> > image element contains the details of the image.
> > Each image element should have two attributes.
> > 1. path: path to the image.
> > 2. domain: domain this particular image belongs to.
> > -->
> > <image
> > path="/home/nirmal/Documents/autoscaler/wso2as-4.1.0-SNAPSHOT.zip"
> > domain="wso2.as.domain"/>
> > <image path="/home/nirmal/Desktop/wso2cep-4.1.0-SNAPSHOT.zip"
> > domain="wso2.cep.domain"/>
> >
> > </agentConfig>
> >
> >
> >
> >
> > On Mon, Feb 27, 2012 at 9:56 AM, Nirmal Fernando <nirmal@wso2.com> wrote:
> >
> > > Hi,
> > >
> > > Please find the sequence type of diagram of starting instance scenario,
> > > attached herewith.
> > >
> > > On Wed, Feb 22, 2012 at 12:36 PM, Afkham Azeez <azeez@wso2.com> wrote:
> > >
> > > >
> > > >
> > > > On Wed, Feb 22, 2012 at 9:50 AM, Selvaratnam Uthaiyashankar <
> > > > shankar@wso2.com> wrote:
> > > >
> > > > > On Wed, Feb 22, 2012 at 8:27 AM, Nirmal Fernando <nirmal@wso2.com>
> > > > > wrote:
> > > > > > Hi Shankar,
> > > > > >
> > > > > > On Wed, Feb 22, 2012 at 8:12 AM, Selvaratnam Uthaiyashankar
> > > > > > <shankar@wso2.com> wrote:
> > > > > > >
> > > > > > > Hi Nirmal,
> > > > > > >
> > > > > > > On Tue, Feb 21, 2012 at 11:04 AM, Nirmal Fernando <nirmal@wso2.com>
> > > > > wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > On Tue, Feb 21, 2012 at 10:18 AM, Nirmal Fernando <
> > > > > nirmal@wso2.com>
> > > > > > > > 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"/>
> > > > > > > > >
> > > > > > > > > .....
> > > > > > > > > </domain>
> > > > > > >
> > > > > > >
> > > > > > > What are these two instances? Why they should be in the
> > > > > configuration
> > > > > > > file? If they are the paths of instances that can be started, then
> > > > > if
> > > > > > > I want to start a third instance what should I do?
> > > > > >
> > > > > >
> > > > > > Agents should know the instances that it can spawn. Thus, each Agent
> > > > > machine
> > > > > > has a configuration file which points to those instances. An Agent
> > > > > can only
> > > > > > spawn instances it has.
> > > > > >
> > > > > > This configuration file will be loaded each time an Agent get
> > > > > registered. So
> > > > > > if you want to add a new instance, you can unregister the Agent,
> > > > > edit the
> > > > > > configuration file and re-register. Then the Agent Service will
> > > > > locate the
> > > > > > newly added instance and list it as an instance that can be spawned.
> > > > >
> > > > > This might become a maintanance problem. Suppose I have a machine
> > > > > which can run 5 instance of stratos service. This service can be ESB,
> > > > > AppServer, GS, MS, Manager, .... We have 13 service, so I have to give
> > > > > 13 * 5 configuration.
> > > > >
> > > > > I would like to give the location of binary pack location for 13
> > > > > services, and when an instance is required, agent can copy the pack
> > > > > into its "working directory" and run it. So, actual instance location
> > > > > is not needed and will be handled by agent. This is the normal way
> > > > > most of the software work (e.g. eucalyptus). In this method, the
> > > > > configuration for all JVM autoscale agent will be same. (can copy the
> > > > > binary pack in same location, working directory can be same location).
> > > > > Based on the request, Agent will copy and start the "instace"
> > > > > dynamically.
> > > > >
> > > >
> > > > Yes, that is how it should be done. It is basically like providing the
> > > > image ID. External invokers will simply ask for an instance of a particular
> > > > binary pack to be started. They don't specify the actual instance.
> > > >
> > > > >
> > > > > WDYT?
> > > > >
> > > > > Shankar
> > > > >
> > > > >
> > > > > >
> > > > > > WDYT?
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Shankar
> > > > > > >
> > > > > > >
> > > > > > > > > .....
> > > > > > > > >
> > > > > > > > > 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
> > > > > > > > > <shankar@wso2.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Mon, Feb 20, 2012 at 8:17 PM, Nirmal Fernando <
> > > > > nirmal@wso2.com>
> > > > > > > > > > wrote:
> > > > > > > > > > > Hi Shankar,
> > > > > > > > > > >
> > > > > > > > > > > On Mon, Feb 20, 2012 at 5:34 PM, Selvaratnam Uthaiyashankar
> > > > > > > > > > > <shankar@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 <
> > > > > nirmal@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/
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > >
> > > > > > > > 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
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > *Afkham Azeez*
> > > > Director of Architecture; WSO2, Inc.; http://wso2.com
> > > > Member; Apache Software Foundation; http://www.apache.org/
> > > > * <http://www.apache.org/>**
> > > > email: **azeez@wso2.com* <azeez@wso2.com>* cell: +94 77 3320919
> > > > blog: **http://blog.afkham.org* <http://blog.afkham.org>*
> > > > twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
> > > > *
> > > > linked-in: **http://lk.linkedin.com/in/afkhamazeez*
> > > > *
> > > > *
> > > > *Lean . Enterprise . Middleware*
> > > >
> > > >
> > >
> > >
> > > --
> > >
> > > 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
> > Carbon-dev@wso2.org
> > http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
> >
> >
> Thanks,
> Dileepa
>
> --
> Dileepa Jayakody,
> Software Engineer, WSO2 Inc.
>
> Lean . Enterprise . Middleware
>
> Mobile : +94777-857616
>
>
> _______________________________________________
> Stratos-dev mailing list
> Stratos-dev@wso2.org
> https://wso2.org/cgi-bin/mailman/listinfo/stratos-dev
>
>
--
Thanks & regards,
Nirmal
Software Engineer- Platform Technologies Team, WSO2 Inc.
Mobile: +94715779733
Blog: http://nirmalfdo.blogspot.com/
[Attachment #5 (text/html)]
<br><br><div class="gmail_quote">On Wed, Feb 29, 2012 at 11:10 AM, Dileepa Jayakody \
<span dir="ltr"><<a href="mailto:dileepa@wso2.com" \
target="_blank">dileepa@wso2.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
Hi,<br><br><br><div class="gmail_quote"><div>On Wed, Feb 29, 2012 at 10:57 AM, Nirmal \
Fernando <span dir="ltr"><<a href="mailto:nirmal@wso2.com" \
target="_blank">nirmal@wso2.com</a>></span> wrote:<br></div> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> Hi,<br><br><div>I have few other concerns to get clarified \
and few thoughts.<br><br>1. Original design was to spawn EC2 instances after the \
number of live instances exceed a threshold value (eg: 25). What if we spawn an EC2 \
instance only if we failed to spawn a JVM instance in any Agent? As far as I see, the \
latter may be bit inefficient but cost effective (since we're not spawning an EC2 \
instance when we can spawn a JVM instance). <br>
<br>2. What's the standard way of specifying Agent's working directory? I \
thought of adding it to the autoscaler_agent_config.xml. Please see [a].<br><br>3. \
How to specify the path to the "autoscaler_agent_config.xml"? Currently it \
is hard coded.<br>
<br>4. How to let AutoscalerService know the EPR of the AgentManagementService? \
Currently it is hard coded. Is it good to assume that both autoscaler service and \
agent management service are hosted in one location, and deriving the EPR of the \
AgentManagementService?<br>
<br>5. Agent should be smart enough to decide whether it can spawn a new JVM \
instance, i.e. whether it has the minimum required memory etc. available. What about \
using Dileepa's boot-up validator component for this purpose?<br>
<br></div></blockquote><div>Are you looking at total RAM or free RAM for this \
purpose?<br></div></div></blockquote><div><br>Agent should satisfy all the minimum \
requirements needed for a server start-up. <br> </div><blockquote class="gmail_quote" \
style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">
<div class="gmail_quote"><div>I think <span>OperatingSystemMXBean: <a \
href="http://www.docjar.com/docs/api/com/sun/management/OperatingSystemMXBean.html" \
target="_blank">http://www.docjar.com/docs/api/com/sun/management/OperatingSystemMXBean.html</a> \
would be helpful to you for this requirement.</span></div>
</div></blockquote><div><br>Thanks for the pointer! <br> </div><blockquote \
class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">
<div class="gmail_quote"><div> </div>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div><div><br>[a]<br><!-- <br>This file should \
specify all the Agent related configuration details.<br>
--><br>
<agentConfig><br><br> <!-- This points to the place where helper services \
such as AgentManagementService <br> and AutoscalerService hosted. --><br> \
<autoscalerHost url="<a href="http://localhost:8080/axis2/services/" \
target="_blank">http://localhost:8080/axis2/services/</a>"/><br><br> \
<!-- Following element should points to the working directory of this Agent. This \
is the directory <br>
where Agent will copy the extratcted carbon-home directories when a new instance \
is spawned.--><br> <workingDir \
path="/home/nirmal/Documents/autoscaler/work/"/><br><br> <!--<br> \
image element contains the details of the image.<br>
Each image element should have two attributes.<br> 1. path: path to the \
image.<br> 2. domain: domain this particular image belongs to.<br> \
--><br> <image \
path="/home/nirmal/Documents/autoscaler/wso2as-4.1.0-SNAPSHOT.zip" \
domain="wso2.as.domain"/><br>
<image path="/home/nirmal/Desktop/wso2cep-4.1.0-SNAPSHOT.zip" \
domain="wso2.cep.domain"/><br><br></agentConfig><div><div></div><div><br><br><br><br><div \
class="gmail_quote">On Mon, Feb 27, 2012 at 9:56 AM, Nirmal Fernando <span \
dir="ltr"><<a href="mailto:nirmal@wso2.com" \
target="_blank">nirmal@wso2.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Hi,<br><br>Please find the sequence type of diagram of \
starting instance scenario, attached herewith. <br><div> <div><br><div \
class="gmail_quote">On Wed, Feb 22, 2012 at 12:36 PM, Afkham Azeez <span \
dir="ltr"><<a href="mailto:azeez@wso2.com" \
target="_blank">azeez@wso2.com</a>></span> wrote:<br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><br><br><div class="gmail_quote"><div><div>On Wed, Feb 22, \
2012 at 9:50 AM, Selvaratnam Uthaiyashankar <span dir="ltr"><<a \
href="mailto:shankar@wso2.com" target="_blank">shankar@wso2.com</a>></span> \
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
<div><div></div><div>On Wed, Feb 22, 2012 at 8:27 AM, Nirmal Fernando <<a \
href="mailto:nirmal@wso2.com" target="_blank">nirmal@wso2.com</a>> wrote:<br> > \
Hi Shankar,<br> ><br>
> On Wed, Feb 22, 2012 at 8:12 AM, Selvaratnam Uthaiyashankar<br>
> <<a href="mailto:shankar@wso2.com" target="_blank">shankar@wso2.com</a>> \
wrote:<br> >><br>
>> Hi Nirmal,<br>
>><br>
>> On Tue, Feb 21, 2012 at 11:04 AM, Nirmal Fernando <<a \
href="mailto:nirmal@wso2.com" target="_blank">nirmal@wso2.com</a>> wrote:<br> \
>> ><br> >> ><br>
>> > On Tue, Feb 21, 2012 at 10:18 AM, Nirmal Fernando <<a \
href="mailto:nirmal@wso2.com" target="_blank">nirmal@wso2.com</a>><br> >> \
> wrote:<br> >> >><br>
>> >> Hi All,<br>
>> >><br>
>> >> I need your views on following.<br>
>> >><br>
>> >> In the Agent side we need to have a configuration file (say<br>
>> >> instances_config.xml) which specifies the paths and names of \
the<br> >> >> instances<br>
>> >> belong to domains.<br>
>> >><br>
>> >> I thought to have following structure:<br>
>> >><br>
>> > Value of the path attribute should change like this:<br>
>> ><br>
>> >><br>
>> >> <domain name="wso2.as.domain"><br>
>> >> <instance name="wso2as-4.1.0-SNAPSHOT"<br>
>> >> path="/home/nirmal/Desktop/wso2as-4.1.0-SNAPSHOT/bin/wso2server.sh"/><br>
>> >> <instance name="wso2as-4.1.0-SNAPSHOT"<br>
>> >> path="/home/nirmal/Temp/wso2as-4.1.0-SNAPSHOT/bin/wso2server.sh"/><br>
>> >><br>
>> >> .....<br>
>> >> </domain><br>
>> >> <domain name="wso2.bps.domain"><br>
>> >> <instance name="wso2bps-4.1.0-SNAPSHOT"<br>
>> >> path="/home/nirmal/Desktop/wso2bps-4.1.0-SNAPSHOT/bin/wso2server.sh"/><br>
>> >> <instance name="wso2bps-4.1.0-SNAPSHOT"<br>
>> >> path="/home/nirmal/Temp/wso2bps-4.1.0-SNAPSHOT/bin/wso2server.sh"/><br>
>> >><br>
>> >> .....<br>
>> >> </domain><br>
>><br>
>><br>
>> What are these two instances? Why they should be in the configuration<br>
>> file? If they are the paths of instances that can be started, then if<br>
>> I want to start a third instance what should I do?<br>
><br>
><br>
> Agents should know the instances that it can spawn. Thus, each Agent machine<br>
> has a configuration file which points to those instances. An Agent can only<br>
> spawn instances it has.<br>
><br>
> This configuration file will be loaded each time an Agent get registered. So<br>
> if you want to add a new instance, you can unregister the Agent, edit the<br>
> configuration file and re-register. Then the Agent Service will locate the<br>
> newly added instance and list it as an instance that can be spawned.<br>
<br>
</div></div>This might become a maintanance problem. Suppose I have a machine<br>
which can run 5 instance of stratos service. This service can be ESB,<br>
AppServer, GS, MS, Manager, .... We have 13 service, so I have to give<br>
13 * 5 configuration.<br>
<br>
I would like to give the location of binary pack location for 13<br>
services, and when an instance is required, agent can copy the pack<br>
into its "working directory" and run it. So, actual instance location<br>
is not needed and will be handled by agent. This is the normal way<br>
most of the software work (e.g. eucalyptus). In this method, the<br>
configuration for all JVM autoscale agent will be same. (can copy the<br>
binary pack in same location, working directory can be same location).<br>
Based on the request, Agent will copy and start the "instace"<br>
dynamically.<br></blockquote><div><br></div></div></div><div>Yes, that is how it \
should be done. It is basically like providing the image ID. External invokers will \
simply ask for an instance of a particular binary pack to be started. They don't \
specify the actual instance. </div>
<div><div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <br>
WDYT?<br>
<br>
Shankar<br>
<div><div></div><div><br>
<br>
><br>
> WDYT?<br>
><br>
>><br>
>><br>
>> Shankar<br>
>><br>
>><br>
>> >> .....<br>
>> >><br>
>> >> WDYT?<br>
>> >><br>
>> >> PS: It is my understanding that the autoscaler component passes \
the<br> >> >> 'domain name' to the "Autoscaler \
Service", when it wants to scale.<br> >> >><br>
>> >><br>
>> >><br>
>> >><br>
>> >> On Mon, Feb 20, 2012 at 9:31 PM, Selvaratnam Uthaiyashankar<br>
>> >> <<a href="mailto:shankar@wso2.com" \
target="_blank">shankar@wso2.com</a>> wrote:<br> >> >>><br>
>> >>> On Mon, Feb 20, 2012 at 8:17 PM, Nirmal Fernando <<a \
href="mailto:nirmal@wso2.com" target="_blank">nirmal@wso2.com</a>><br> >> \
>>> wrote:<br> >> >>> > Hi Shankar,<br>
>> >>> ><br>
>> >>> > On Mon, Feb 20, 2012 at 5:34 PM, Selvaratnam \
Uthaiyashankar<br> >> >>> > <<a href="mailto:shankar@wso2.com" \
target="_blank">shankar@wso2.com</a>> wrote:<br> >> >>> \
>><br> >> >>> >> Hi Nirmal,<br>
>> >>> >><br>
>> >>> >> Good progress!. we can do a review on the work already \
done.<br> >> >>> ><br>
>> >>> ><br>
>> >>> > Thanks, will arrange a review this week.<br>
>> >>> ><br>
>> >>> >><br>
>> >>> >><br>
>> >>> >> Did you try the agent in windows?<br>
>> >>> ><br>
>> >>> ><br>
>> >>> > No, I didn't!<br>
>> >>> ><br>
>> >>> >><br>
>> >>> >> Is it using any native code?<br>
>> >>> ><br>
>> >>> ><br>
>> >>> > It needs to use native code in cases like spawning a new \
JVM (in<br> >> >>> > Ubuntu<br>
>> >>> > we<br>
>> >>> > need /bin/sh to run the script 'wso2server.sh' in \
windows we need to<br> >> >>> > run the<br>
>> >>> > batch file.<br>
>> >>> > But I believe this can be handled within the code it self \
by<br> >> >>> > checking<br>
>> >>> > the OS<br>
>> >>> > name and execute appropriate commands!<br>
>> >>> ><br>
>> >>> >><br>
>> >>> >><br>
>> >>> >> See some comments below.<br>
>> >>> >><br>
>> >>> >> On Sat, Feb 18, 2012 at 11:10 PM, Nirmal Fernando \
<<a href="mailto:nirmal@wso2.com" target="_blank">nirmal@wso2.com</a>><br> \
>> >>> >> wrote:<br> >> >>> >> > Hi \
All,<br> >> >>> >> ><br>
>> >>> >> > I've started to implement 'new autoscaler \
architecture' [1] on<br> >> >>> >> > February<br>
>> >>> >> > 8th.<br>
>> >>> >> > After having a discussion with Azeez, we came up \
with three<br> >> >>> >> > milestones<br>
>> >>> >> > for<br>
>> >>> >> > the first iteration.<br>
>> >>> >> ><br>
>> >>> >> ><br>
>> >>> >> ><br>
>> >>> >> > \
-------------------------------------------------------------------------------------- \
-----------------------------------------------------------------------------------------------------------------------------<br>
>> >>> >> ><br>
>> >>> >> > M1: Make a WS call spawns a new JVM instance \
& make the new<br> >> >>> >> > instance<br>
>> >>> >> > joins<br>
>> >>> >> > the cluster with hard coded Agents.<br>
>> >>> >> ><br>
>> >>> >> > M2: Finish Agent registration related parts and \
spawn a new<br> >> >>> >> > instance<br>
>> >>> >> > in<br>
>> >>> >> > a<br>
>> >>> >> > selected Agent.<br>
>> >>> >> ><br>
>> >>> >> > M3: Let current autoscaler component calls \
'AutoscalerService'<br> >> >>> >> > and<br>
>> >>> >> > spawns a<br>
>> >>> >> > new JVM instance in a selected Agent. Also \
applying WS security.<br> >> >>> >> ><br>
>> >>> >> ><br>
>> >>> >> ><br>
>> >>> >> ><br>
>> >>> >> > \
-------------------------------------------------------------------------------------- \
-----------------------------------------------------------------------------------------------------------------------------<br>
>> >>> >> ><br>
>> >>> >> > I've attached set of images which depicts \
different stages of new<br> >> >>> >> > architecture. Reading \
order of images is as follows:<br> >> >>> >> ><br>
>> >>> >> > agent-reg --> autoscaler --> spawn --> \
cluster<br> >> >>> >> ><br>
>> >>> >> ><br>
>> >>> >> > M1 is already finished.<br>
>> >>> >> ><br>
>> >>> >> > I've almost done the Agent registration (M2) \
aspect.<br> >> >>> >> ><br>
>> >>> >> > What it does now?<br>
>> >>> >> ><br>
>> >>> >> > AgentManagementService and AutoscalerService \
should be deployed<br> >> >>> >> > in<br>
>> >>> >> > the<br>
>> >>> >> > back-end server. (say: IP is 192.168.1.2)<br>
>> >>> >> ><br>
>> >>> >> > AgentService should be deployed in machines (i.e. \
where new JVM<br> >> >>> >> > instances<br>
>> >>> >> > will be spawned). (say: IP is 192.168.1.3)<br>
>> >>> >> ><br>
>> >>> >> > AgentService do a web service call (eg: curl -X \
GET<br> >> >>> >> > <a \
href="http://localhost:8080/axis2/services/AgentService/agent" \
target="_blank">http://localhost:8080/axis2/services/AgentService/agent</a>) to<br> \
>> >>> >> > AgentManagementService and get registered. \
Then<br> >> >>> >> > AgentManagementService<br>
>> >>> >> > stores the URL (eg:<br>
>> >>> >> > <a \
href="http://192.168.1.3:8080/axis2/services/AgentService/" \
target="_blank">http://192.168.1.3:8080/axis2/services/AgentService/</a>) of<br> \
>> >>> >> > that particular request.<br> >> \
>>> >> ><br> >> >>> >> > When autoscaler \
API (implementing this is M3) wanted to spawn a<br> >> >>> >> \
> new<br> >> >>> >> > instance<br>
>> >>> >> > (JVM or EC2 or anything else), it should call \
AutoscalerService<br> >> >>> >> > (eg:<br>
>> >>> >> > curl<br>
>> >>> >> > --data "instanceName=as" -X POST<br>
>> >>> >> ><br>
>> >>> >> > <a \
href="http://192.168.1.2:8080/axis2/services/AutoscalerService/instance" \
target="_blank">http://192.168.1.2:8080/axis2/services/AutoscalerService/instance</a>).<br>
>> >>> >> > Then<br>
>> >>> >> > AutoscalerService decides which kind of instance \
to spawn.<br> >> >>> >> ><br>
>> >>> >> > If AutoscalerService decides to spawn a JVM \
instance, it creates<br> >> >>> >> > a<br>
>> >>> >> > new<br>
>> >>> >> > JVMAdaptor instance. JVMAdaptor then calls (eg: \
curl -X GET<br> >> >>> >> ><br>
>> >>> >> > <a \
href="http://192.168.1.2:8080/axis2/services/AgentManagementService/agent" \
target="_blank">http://192.168.1.2:8080/axis2/services/AgentManagementService/agent</a>)<br>
>> >>> >> > AgentManagementService in order to pick an \
Agent.<br> >> >>> >> > AgentManagementService<br>
>> >>> >> > picks an Agent in a round robin manner and sends \
back that<br> >> >>> >> > Agent's<br>
>> >>> >> > EPR<br>
>> >>> >> > (<a \
href="http://192.168.1.3:8080/axis2/services/AgentService/" \
target="_blank">http://192.168.1.3:8080/axis2/services/AgentService/</a>) to<br> \
>> >>> >> > JVMAdaptor.<br> >> >>> >> \
> Then<br> >> >>> >> > JVMAdaptor does a web service call \
to that particular<br> >> >>> >> > AgentService<br>
>> >>> >> > and<br>
>> >>> >> > asked<br>
>> >>> >> > it to spawn the requested instance (instance is \
yet hard coded).<br> >> >>> >> ><br>
>> >>> >> > Spawned instance then joins the cluster.<br>
>> >>> >> ><br>
>> >>> >> ><br>
>> >>> >> > Current observations:<br>
>> >>> >> ><br>
>> >>> >> > Currently starting instance aspect is done.<br>
>> >>> >> ><br>
>> >>> >> > I've tested this using 2 machines, and \
starting instance works<br> >> >>> >> > fine.<br>
>> >>> >> ><br>
>> >>> >> > It is observed that the spawned JVM instances get \
killed when you<br> >> >>> >> > issue<br>
>> >>> >> > 'ctrl+c' in the terminal where axis2 \
running. But when I killed<br> >> >>> >> > axis2server.sh \
process only, the new JAVA process wasn't get<br> >> >>> >> \
> killed.<br> >> >>> >> > To<br>
>> >>> >> > avoid process get killing when issue ctrl+c, we \
might need to<br> >> >>> >> > handle<br>
>> >>> >> > SIGINT<br>
>> >>> >> > [2]. Can't we be happy with the fact that it \
doesn't get killed<br> >> >>> >> > after<br>
>> >>> >> > killing axis2server.sh?<br>
>> >>> >><br>
>> >>> >> JVMs (which were created) should live even if you \
kill the agent.<br> >> >>> >><br>
>> >>> ><br>
>> >>> > Yes, but the problem is how you kill! If you use kill -9 \
and kills<br> >> >>> > Axis2<br>
>> >>> > related process (Axis2 is where Agent Service is \
deployed), spawned<br> >> >>> > JVM<br>
>> >>> > instances aren't get killed.<br>
>> >>> > Anyway will research a bit more, I understand that spawned \
instance<br> >> >>> > should<br>
>> >>> > never get killed, unless it is asked to!<br>
>> >>> ><br>
>> >>> >><br>
>> >>> >> ><br>
>> >>> >> ><br>
>> >>> >> > Work to be done:<br>
>> >>> >> ><br>
>> >>> >> > Terminating and finding instance aspects should \
be addressed.<br> >> >>> >><br>
>> >>> >> You have to keep track of which JVMs/VMs created by \
the autoscaler.<br> >> >>> >> Otherwise you will not be able to \
stop them when you want to scale<br> >> >>> >> down. I believe, \
this information should be stored/kept with<br> >> >>> >> \
"autoscaler service".<br> >> >>> ><br>
>> >>> ><br>
>> >>> > I have started to implement this part today! According to \
the design<br> >> >>> > 'Autoscaler Service' is only \
responsible for<br> >> >>> > deciding the type of instance it \
should be spawned. That is a JVM<br> >> >>> > instance<br>
>> >>> > or an EC2 instance or something else. Thus, it keeps track \
of<br> >> >>> > the type of instance spawned.<br>
>> >>> ><br>
>> >>> > It is JVM Adaptor which keeps track of instances spawned \
in each<br> >> >>> > Agent.<br>
>> >>><br>
>> >>> +1. It should be JVM adapter for JVM instances and EC2 adapter \
for EC2<br> >> >>> instance, etc.<br>
>> >>><br>
>> >>> Shankar<br>
>> >>><br>
>> >>><br>
>> >>> ><br>
>> >>> > And it is respective Agent Service that kills an instance, \
upon a<br> >> >>> > request!<br>
>> >>> ><br>
>> >>> ><br>
>> >>> >><br>
>> >>> >><br>
>> >>> >> > The 'sad side' (when things go wrong) \
should be addressed.<br> >> >>> >> > AgentServices should \
know EPR of AgentManagementService (this is<br> >> >>> >> > \
hard<br> >> >>> >> > coded<br>
>> >>> >> > now). Should read from a config file?<br>
>> >>> >><br>
>> >>> >> +1 fore reading from config file.<br>
>> >>> ><br>
>> >>> ><br>
>> >>> > Great!<br>
>> >>> ><br>
>> >>> >><br>
>> >>> >><br>
>> >>> >><br>
>> >>> >> > JVMAdaptor should keep a map of Agent EPR to \
AgentService client,<br> >> >>> >> > to<br>
>> >>> >> > avoid<br>
>> >>> >> > creating multiple clients to access the same \
Agent.<br> >> >>> >> > AgentService should keep a count of \
spawned instances and get<br> >> >>> >> > itself<br>
>> >>> >> > unregistered if it can't handle any new \
instances (threshold<br> >> >>> >> > value<br>
>> >>> >> > should be<br>
>> >>> >> > decided). And when it feels (another threshold) \
that it can<br> >> >>> >> > handle<br>
>> >>> >> > new<br>
>> >>> >> > instances it should register again.<br>
>> >>> >> > Autoscaler API should be designed.<br>
>> >>> >> > Should port EC2 client to EC2Adaptor.<br>
>> >>> >> > Should test the whole scenario.<br>
>> >>> >> ><br>
>> >>> >> ><br>
>> >>> >> > I appreciate your comments/thoughts on above \
facts.<br> >> >>> >> ><br>
>> >>> >> ><br>
>> >>> >> > [1]<br>
>> >>> >> ><br>
>> >>> >> ><br>
>> >>> >> > <a \
href="http://mail.wso2.org/mailarchive/architecture/2011-October/006414.html" \
target="_blank">http://mail.wso2.org/mailarchive/architecture/2011-October/006414.html</a><br>
>> >>> >> ><br>
>> >>> >> > [2] <a \
href="http://www.cons.org/cracauer/sigint.html" \
target="_blank">http://www.cons.org/cracauer/sigint.html</a><br> >> \
>>> >> ><br> >> >>> >> ><br>
>> >>> >> ><br>
>> >>> >> > --<br>
>> >>> >> ><br>
>> >>> >> > Thanks & regards,<br>
>> >>> >> > Nirmal<br>
>> >>> >> ><br>
>> >>> >> > Software Engineer- Platform Technologies Team, \
WSO2 Inc.<br> >> >>> >> > Mobile: <a \
href="tel:%2B94715779733" value="+94715779733" target="_blank">+94715779733</a><br> \
>> >>> >> > Blog: <a href="http://nirmalfdo.blogspot.com/" \
target="_blank">http://nirmalfdo.blogspot.com/</a><br> >> >>> \
>><br> >> >>> >><br>
>> >>> >><br>
>> >>> >> --<br>
>> >>> >> S.Uthaiyashankar<br>
>> >>> >> Senior Architect & Senior Manager<br>
>> >>> >> WSO2 Inc.<br>
>> >>> >> <a href="http://wso2.com/" \
target="_blank">http://wso2.com/</a> - "lean . enterprise . middleware"<br> \
>> >>> >><br> >> >>> >> Phone: <a \
href="tel:%2B94%20714897591" value="+94714897591" target="_blank">+94 \
714897591</a><br> >> >>> ><br>
>> >>> ><br>
>> >>> ><br>
>> >>> ><br>
>> >>> > --<br>
>> >>> ><br>
>> >>> > Thanks & regards,<br>
>> >>> > Nirmal<br>
>> >>> ><br>
>> >>> > Software Engineer- Platform Technologies Team, WSO2 \
Inc.<br> >> >>> > Mobile: <a href="tel:%2B94715779733" \
value="+94715779733" target="_blank">+94715779733</a><br> >> >>> > \
Blog: <a href="http://nirmalfdo.blogspot.com/" \
target="_blank">http://nirmalfdo.blogspot.com/</a><br> >> >>><br>
>> >>><br>
>> >>><br>
>> >>> --<br>
>> >>> S.Uthaiyashankar<br>
>> >>> Senior Architect & Senior Manager<br>
>> >>> WSO2 Inc.<br>
>> >>> <a href="http://wso2.com/" target="_blank">http://wso2.com/</a> \
- "lean . enterprise . middleware"<br> >> >>><br>
>> >>> Phone: <a href="tel:%2B94%20714897591" value="+94714897591" \
target="_blank">+94 714897591</a><br> >> >><br>
>> >><br>
>> >><br>
>> >><br>
>> >> --<br>
>> >><br>
>> >> Thanks & regards,<br>
>> >> Nirmal<br>
>> >><br>
>> >> Software Engineer- Platform Technologies Team, WSO2 Inc.<br>
>> >> Mobile: <a href="tel:%2B94715779733" value="+94715779733" \
target="_blank">+94715779733</a><br> >> >> Blog: <a \
href="http://nirmalfdo.blogspot.com/" \
target="_blank">http://nirmalfdo.blogspot.com/</a><br> >> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> ><br>
>> > Thanks & regards,<br>
>> > Nirmal<br>
>> ><br>
>> > Software Engineer- Platform Technologies Team, WSO2 Inc.<br>
>> > Mobile: <a href="tel:%2B94715779733" value="+94715779733" \
target="_blank">+94715779733</a><br> >> > Blog: <a \
href="http://nirmalfdo.blogspot.com/" \
target="_blank">http://nirmalfdo.blogspot.com/</a><br> >><br>
>><br>
>><br>
>> --<br>
>> S.Uthaiyashankar<br>
>> Senior Architect & Senior Manager<br>
>> WSO2 Inc.<br>
>> <a href="http://wso2.com/" target="_blank">http://wso2.com/</a> - "lean \
. enterprise . middleware"<br> >><br>
>> Phone: <a href="tel:%2B94%20714897591" value="+94714897591" \
target="_blank">+94 714897591</a><br> ><br>
><br>
><br>
><br>
> --<br>
><br>
> Thanks & regards,<br>
> Nirmal<br>
><br>
> Software Engineer- Platform Technologies Team, WSO2 Inc.<br>
> Mobile: <a href="tel:%2B94715779733" value="+94715779733" \
target="_blank">+94715779733</a><br> > Blog: <a \
href="http://nirmalfdo.blogspot.com/" \
target="_blank">http://nirmalfdo.blogspot.com/</a><br> <br>
<br>
<br>
--<br>
S.Uthaiyashankar<br>
Senior Architect & Senior Manager<br>
WSO2 Inc.<br>
<a href="http://wso2.com/" target="_blank">http://wso2.com/</a> - "lean . \
enterprise . middleware"<br> <br>
Phone: <a href="tel:%2B94%20714897591" value="+94714897591" target="_blank">+94 \
714897591</a><br> </div></div></blockquote></div></div></div><span><font \
color="#888888"><br><br clear="all"><div><br></div>-- <br><b>Afkham \
Azeez</b><br><font face="verdana, sans-serif"><span style="font-size:x-small"><span \
style="font-family:arial;font-size:small"><font face="verdana, sans-serif"><span \
style="font-size:x-small">Director of Architecture</span></font>; <span \
style="font-size:x-small">WSO2, Inc.; </span><a href="http://wso2.com/" \
target="_blank"><span \
style="font-size:x-small">http://wso2.com</span></a></span></span></font><span \
style="font-size:x-small"><br>
<span style="font-size:small"><span style="font-size:x-small">Member; Apache Software \
Foundation; </span><span style="font-size:x-small"><a href="http://www.apache.org/" \
target="_blank">http://www.apache.org/</a></span></span><br>
</span><div><i><span style="font-size:x-small"><a href="http://www.apache.org/" \
target="_blank"></a></span></i><i><span style="font-size:x-small"><br>email: \
</span></i><a href="mailto:azeez@wso2.com" target="_blank"><i><span \
style="font-size:x-small">azeez@wso2.com</span></i></a><i><span \
style="font-size:x-small"> cell: <a href="tel:%2B94%2077%203320919" \
value="+94773320919" target="_blank">+94 77 3320919</a><br>
blog: </span></i><a href="http://blog.afkham.org" target="_blank"><i><span \
style="font-size:x-small">http://blog.afkham.org</span></i></a><i><span \
style="font-size:x-small"><br>twitter: </span></i><a \
href="http://twitter.com/afkham_azeez" target="_blank"><i><span \
style="font-size:x-small">http://twitter.com/afkham_azeez</span></i></a><i><span \
style="font-size:x-small"><br>
linked-in: </span></i><i><span style="font-size:x-small"><a \
href="http://lk.linkedin.com/in/afkhamazeez" \
target="_blank">http://lk.linkedin.com/in/afkhamazeez</a></span></i><br><div></div><div><i><br></i></div><div><i><span \
style="font-style:normal"><span style="font-size:x-small">Lean . Enterprise . \
Middleware</span></span></i></div>
</div><br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><br>Thanks & \
regards,<br>Nirmal<br><br>Software Engineer- Platform Technologies Team, WSO2 \
Inc.<br>Mobile: <a href="tel:%2B94715779733" value="+94715779733" \
target="_blank">+94715779733</a><br>
Blog: <a href="http://nirmalfdo.blogspot.com/" \
target="_blank">http://nirmalfdo.blogspot.com/</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><br>Thanks & \
regards,<br>Nirmal<br><br>Software Engineer- Platform Technologies Team, WSO2 \
Inc.<br>Mobile: <a href="tel:%2B94715779733" value="+94715779733" \
target="_blank">+94715779733</a><br>
Blog: <a href="http://nirmalfdo.blogspot.com/" \
target="_blank">http://nirmalfdo.blogspot.com/</a><br>
</div></div><br></div></div><div>_______________________________________________<br>
Carbon-dev mailing list<br>
<a href="mailto:Carbon-dev@wso2.org" target="_blank">Carbon-dev@wso2.org</a><br>
<a href="http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev" \
target="_blank">http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev</a><br> \
<br></div></blockquote></div><br>Thanks,<br>Dileepa<br clear="all"><br>-- <br>Dileepa \
Jayakody,<br>Software Engineer, WSO2 Inc.<div><br>Lean . Enterprise . \
Middleware<br><br></div>Mobile : <a href="tel:%2B94777-857616" value="+94777857616" \
target="_blank">+94777-857616</a><br>
<br>
<br>_______________________________________________<br>
Stratos-dev mailing list<br>
<a href="mailto:Stratos-dev@wso2.org" target="_blank">Stratos-dev@wso2.org</a><br>
<a href="https://wso2.org/cgi-bin/mailman/listinfo/stratos-dev" \
target="_blank">https://wso2.org/cgi-bin/mailman/listinfo/stratos-dev</a><br> \
<br></blockquote></div><br><br clear="all"><br>-- <br><br>Thanks & \
regards,<br>Nirmal<br><br>Software Engineer- Platform Technologies Team, WSO2 \
Inc.<br>Mobile: <a href="tel:%2B94715779733" value="+94715779733" \
target="_blank">+94715779733</a><br>
Blog: <a href="http://nirmalfdo.blogspot.com/" \
target="_blank">http://nirmalfdo.blogspot.com/</a><br>
_______________________________________________
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic