As I found this problem occurs as follows: - When an application is deployed, Autoscaler publishes Application Created event. - Soon after Autoscaler makes a call to Stratos Manager to add an Application SignUp. - At this point Stratos Manager has not received the Application Created event. - As a result it throws application not found exception.
Seems like event processing is much slower than a service call. Might need to review this flow and change the logic. Thanks On Sat, Jan 10, 2015 at 12:00 AM, Lahiru Sandaruwan <[email protected]> wrote: > Thanks Imesh. > > On Fri, Jan 9, 2015 at 11:52 PM, Imesh Gunaratne <[email protected]> wrote: > >> Hi Lahiru, >> >> No, there shouldn't be any impact on single-tenant applications from the >> above implementation. Will investigate and see what's causing this. >> >> Thanks >> >> On Fri, Jan 9, 2015 at 11:47 PM, Lahiru Sandaruwan <[email protected]> >> wrote: >> >>> Hi Imesh, >>> >>> It seems my single tenant app[1] is failing. Do i need to change it? >>> >>> Error is at [2]. >>> >>> Thanks. >>> >>> [1] >>> https://github.com/rekathiru/grouping-samples/tree/master/dependency_scaling/sample_groups >>> >>> [2] >>> >>> [2015-01-09 23:33:27,758] INFO >>> {org.apache.stratos.autoscaler.services.impl.AutoScalerServiceImpl} - >>> Adding application signup: [application-id] app_group_v2 >>> >>> [2015-01-09 23:33:27,773] INFO >>> {org.apache.stratos.manager.components.ApplicationSignUpHandler} - Adding >>> application signup: [application-id] app_group_v2 [tenant-id] -1234 >>> >>> [2015-01-09 23:33:27,774] ERROR >>> {org.apache.stratos.manager.components.ApplicationSignUpHandler} - Could >>> not add application signup >>> >>> java.lang.RuntimeException: Application not found: [application-id] >>> app_group_v2 >>> >>> at >>> org.apache.stratos.manager.components.ApplicationSignUpHandler.addApplicationSignUp(ApplicationSignUpHandler.java:72) >>> >>> at >>> org.apache.stratos.manager.services.impl.StratosManagerServiceImpl.addApplicationSignUp(StratosManagerServiceImpl.java:55) >>> >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> >>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >>> >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> >>> at java.lang.reflect.Method.invoke(Method.java:606) >>> >>> at >>> org.apache.axis2.rpc.receivers.RPCUtil.invokeServiceClass(RPCUtil.java:212) >>> >>> at >>> org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RPCMessageReceiver.java:117) >>> >>> at >>> org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40) >>> >>> at >>> org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:110) >>> >>> at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:180) >>> >>> On Wed, Jan 7, 2015 at 3:33 PM, Imesh Gunaratne <[email protected]> >>> wrote: >>> >>>> Hi Devs, >>>> >>>> I have now completed Application SignUp functionality for Multi-Tenant >>>> applications and pushed changes to master branch. >>>> >>>> This is how it works: >>>> - There is no application signup support for single-tenant >>>> applications, it's only available for multi-tenant applications. >>>> - For single-tenant applications Autoscaler will create an applicaiton >>>> signup internally but it will not be visible via the API. >>>> - An application sign up may contain a list of artifact repositories: >>>> >>>> { >>>> "applicationId":"single-cartridge-app", >>>> "artifactRepositories":[ >>>> { >>>> "alias":"php", >>>> "privateRepo":false, >>>> "repoUrl":" >>>> https://github.com/imesh/stratos-php-applications.git";, >>>> "repoUsername":"", >>>> "repoPassword":"" >>>> }, >>>> { >>>> "alias":"tomcat", >>>> "privateRepo":false, >>>> "repoUrl":" >>>> https://github.com/imesh/stratos-tomcat-applications.git";, >>>> "repoUsername":"", >>>> "repoPassword":"" >>>> } >>>> ] >>>> } >>>> >>>> - Following API methods are introduced to manage application signups: >>>> POST /applications/{applicationId}/signups >>>> GET /applications/{applicationId}/signups/{signUpId} >>>> GET /applications/{applicationId}/signups/ >>>> DELETE /applications/{applicationId}/signups/{signUpId} >>>> >>>> Thanks >>>> >>>> On Tue, Jan 6, 2015 at 7:45 PM, Imesh Gunaratne <[email protected]> >>>> wrote: >>>> >>>>> I have now completed the initial version of Application SignUp support >>>>> for multi-tenant applications. Changes were pushed to master branch. Now >>>>> I'm working on fixing the logic which notify ADC to send Artifact Update >>>>> event on Git updates. >>>>> >>>>> Please find latest sample artifacts here: >>>>> https://github.com/imesh/stratos-samples.git >>>>> >>>>> Thanks >>>>> >>>>> On Mon, Jan 5, 2015 at 12:32 PM, Lakmal Warusawithana <[email protected] >>>>> > wrote: >>>>> >>>>>> Thing is all other sunscribleInfo used in AS and only repo info used >>>>>> in SM. In the single tenant, all these come to AS when deploying the >>>>>> application and we need to pass subscribleInfo to SM for ADC usage. MT >>>>>> scenario subscribleInfo comes to SM. If consider all scenario, IMO this >>>>>> is >>>>>> a good move. >>>>>> >>>>>> On Mon, Jan 5, 2015 at 12:24 PM, Sajith Kariyawasam <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Jan 5, 2015 at 12:13 PM, Imesh Gunaratne <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Following is the current definition of Subscribable Info in an >>>>>>>> application: >>>>>>>> >>>>>>>> { >>>>>>>> "applicationId":"single-cartridge-app", >>>>>>>> "alias":"single-cartridge-app", >>>>>>>> "components":{ >>>>>>>> "cartridges":[ >>>>>>>> { >>>>>>>> "type":"php", >>>>>>>> "cartridgeMin":1, >>>>>>>> "cartridgeMax":10, >>>>>>>> "*subscribableInfo*":{ >>>>>>>> "alias":"php", >>>>>>>> "autoscalingPolicy":"autoscale-policy-1", >>>>>>>> "privateRepo":false, >>>>>>>> "repoUrl":" >>>>>>>> https://github.com/imesh/stratos-php-applications.git";, >>>>>>>> "repoUsername":"", >>>>>>>> "repoPassword":"" >>>>>>>> } >>>>>>>> } >>>>>>>> ] >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> Here I think we can move artifact repository information to an >>>>>>>> inner block within Subscribable Info as follows since we need to store >>>>>>>> it >>>>>>>> separately in SM, please add your thoughts: >>>>>>>> >>>>>>>> { >>>>>>>> "applicationId":"single-cartridge-app", >>>>>>>> "alias":"single-cartridge-app", >>>>>>>> "components":{ >>>>>>>> "cartridges":[ >>>>>>>> { >>>>>>>> "type":"php", >>>>>>>> "cartridgeMin":1, >>>>>>>> "cartridgeMax":10, >>>>>>>> "*subscribableInfo*":{ >>>>>>>> "alias":"php", >>>>>>>> "autoscalingPolicy":"autoscale-policy-1", >>>>>>>> "*artifactRepository*":{ >>>>>>>> "privateRepo":false, >>>>>>>> "repoUrl":" >>>>>>>> https://github.com/imesh/stratos-php-applications.git";, >>>>>>>> "repoUsername":"", >>>>>>>> "repoPassword":"" >>>>>>>> } >>>>>>>> } >>>>>>>> } >>>>>>>> ] >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>> >>>>>>> Imesh, >>>>>>> >>>>>>> Can't we just store the subscribableInfo object with the repo >>>>>>> information? I can't clearly see any advantage of moving it to a >>>>>>> separate >>>>>>> object, besides this will result a change of Domain Objects / API s? >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> On Mon, Jan 5, 2015 at 11:50 AM, Imesh Gunaratne <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> +1 for the design Lakmal! >>>>>>>>> >>>>>>>>> Will store subscribable information in SM and expose a service to >>>>>>>>> manage them. For single tenant applications will make a call from >>>>>>>>> Autoscaler to SM to register subscribable information. For >>>>>>>>> Multi-Tenant >>>>>>>>> applications will expose a REST API method to signup. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> On Mon, Jan 5, 2015 at 11:45 AM, Lakmal Warusawithana < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> IMO we can handle it without major refactor. We can have property >>>>>>>>>> in application to define whether single tenant or MT. MT >>>>>>>>>> applications are >>>>>>>>>> only create and deploy by Super tenant. If MT application deployed, >>>>>>>>>> we can >>>>>>>>>> expose a API, to get subscribe info when signup to the MT >>>>>>>>>> application by >>>>>>>>>> tenant. >>>>>>>>>> >>>>>>>>>> Further, we should store all subscribe info in SM. To generalize >>>>>>>>>> the process, for the single tenant, we should call internal signup >>>>>>>>>> call >>>>>>>>>> with subscribe info and store them in SM. Then we have single place >>>>>>>>>> store >>>>>>>>>> all subscribe info and ADC can use it for artifact distribution. >>>>>>>>>> >>>>>>>>>> On Sun, Jan 4, 2015 at 5:43 PM, Imesh Gunaratne <[email protected] >>>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> Hi Devs, >>>>>>>>>>> >>>>>>>>>>> At present with service grouping functionality an application >>>>>>>>>>> can have only one subscription. This subscription may include >>>>>>>>>>> multiple >>>>>>>>>>> subscribable information blocks for multiple cartridges. >>>>>>>>>>> >>>>>>>>>>> To support Multi-Tenant applications which may include >>>>>>>>>>> Multi-Tenant cartridges we should be able to manage multiple >>>>>>>>>>> subscriptions >>>>>>>>>>> for each cartridge. Currently we do not have a concept of >>>>>>>>>>> subscribing to >>>>>>>>>>> applications. >>>>>>>>>>> >>>>>>>>>>> Shall we introduce a new artifact called Application >>>>>>>>>>> Subscription and move subscribable information blocks from >>>>>>>>>>> Application >>>>>>>>>>> definition to it? >>>>>>>>>>> >>>>>>>>>>> Then the workflow may change as follows: >>>>>>>>>>> - Add autoscaling policy >>>>>>>>>>> - Add cartridges >>>>>>>>>>> - Add groups >>>>>>>>>>> - Add application >>>>>>>>>>> - Deploy application >>>>>>>>>>> - Subscribe to application: >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Imesh Gunaratne >>>>>>>>>>> >>>>>>>>>>> Technical Lead, WSO2 >>>>>>>>>>> Committer & PMC Member, Apache Stratos >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Lakmal Warusawithana >>>>>>>>>> Vice President, Apache Stratos >>>>>>>>>> Director - Cloud Architecture; WSO2 Inc. >>>>>>>>>> Mobile : +94714289692 >>>>>>>>>> Blog : http://lakmalsview.blogspot.com/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Imesh Gunaratne >>>>>>>>> >>>>>>>>> Technical Lead, WSO2 >>>>>>>>> Committer & PMC Member, Apache Stratos >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Imesh Gunaratne >>>>>>>> >>>>>>>> Technical Lead, WSO2 >>>>>>>> Committer & PMC Member, Apache Stratos >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Sajith Kariyawasam* >>>>>>> >>>>>>> *Committer and PMC member, Apache Stratos,WSO2 Inc., http://wso2.com >>>>>>> <http://wso2.com>AMIE (SL)Mobile: +94772269575* >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Lakmal Warusawithana >>>>>> Vice President, Apache Stratos >>>>>> Director - Cloud Architecture; WSO2 Inc. >>>>>> Mobile : +94714289692 >>>>>> Blog : http://lakmalsview.blogspot.com/ >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Imesh Gunaratne >>>>> >>>>> Technical Lead, WSO2 >>>>> Committer & PMC Member, Apache Stratos >>>>> >>>> >>>> >>>> >>>> -- >>>> Imesh Gunaratne >>>> >>>> Technical Lead, WSO2 >>>> Committer & PMC Member, Apache Stratos >>>> >>> >>> >>> >>> -- >>> -- >>> Lahiru Sandaruwan >>> Committer and PMC member, Apache Stratos, >>> Senior Software Engineer, >>> WSO2 Inc., http://wso2.com >>> lean.enterprise.middleware >>> >>> email: [email protected] blog: http://lahiruwrites.blogspot.com/ >>> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146 >>> >>> >> >> >> -- >> Imesh Gunaratne >> >> Technical Lead, WSO2 >> Committer & PMC Member, Apache Stratos >> > > > > -- > -- > Lahiru Sandaruwan > Committer and PMC member, Apache Stratos, > Senior Software Engineer, > WSO2 Inc., http://wso2.com > lean.enterprise.middleware > > email: [email protected] blog: http://lahiruwrites.blogspot.com/ > linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146 > > -- Imesh Gunaratne Technical Lead, WSO2 Committer & PMC Member, Apache Stratos
