Hi Manfred, See my comments inline.
On Mon, Aug 18, 2014 at 3:08 PM, Manfred Herrmann < [email protected]> wrote: > I would like to test the workflows, lifecycles and usability of the > AppCloud and ApiCloud. But with at least 3 to 4 tries it was not possible > to start testing. The "response-time" of the public available test-clouds > is more like "unusable". In a Enterprise-DevOps usecase the developers like > very fast responses. Or at least deep information about "what is going on". > The admins like the shell for lightweight and quick responses. > Agree. AFAIK, at the moment AF team is working on presenting more information to the user on what is going on. So, this will get improved by the time. Regarding the slowness you are experiencing, we are also investigating and hope to fix the issues we fin. > > proposal: "fault tolerant" > A high-level workflow/process/statechart to track all main states. This > workflow should have a graphical-view with info about the history of each > state and the actual open state-change or event/transition. The info should > always include time-stamps. > After some release-cycles of AF and AM the "button retry > transition/state-change" should in all possible states available. So in the > end no deadlock possible. > > What do you think ... is that feasible and useful? > This looks a whole new feature to AF and AM. IMO, those products teams are the best to decide on the feasibility of this. > > > 2014-08-18 10:46 GMT+02:00 Nirmal Fernando <[email protected]>: > > +1 for an asynchronous model. >> >> >> On Mon, Aug 18, 2014 at 2:06 PM, Amila Maha Arachchi <[email protected]> >> wrote: >> >>> Any thoughts? >>> >>> >>> On Fri, Aug 15, 2014 at 10:45 AM, Amila Maha Arachchi <[email protected]> >>> wrote: >>> >>>> AF team, >>>> >>>> Its needless to say that there are several possible failure points in >>>> AF, hence in App Cloud. One such place is making the tenants subscribed to >>>> the dev, test and prod stratos environments. Due to some reason, if this >>>> step fails, then, thats the end of story for that tenant. >>>> >>>> Proposal: >>>> >>>> Hand over the subscription requests to a queue (doe not need to be JMS >>>> queue) and let a task do the subscription taking them from the queue. If >>>> the subscription is successful, remove it from the queue, else put it back, >>>> which will make the task to retry. >>>> >>>> AFAIK, this subscription step does not need to be synchronous. So, the >>>> above change has no impact to the tenant creation flow. >>>> >>>> WDYT? >>>> >>>> Regards, >>>> Amila. >>>> >>>> -- >>>> *Amila Maharachchi* >>>> Senior Technical Lead >>>> WSO2, Inc.; http://wso2.com >>>> >>>> Blog: http://maharachchi.blogspot.com >>>> Mobile: +94719371446 >>>> >>>> >>> >>> >>> -- >>> *Amila Maharachchi* >>> Senior Technical Lead >>> WSO2, Inc.; http://wso2.com >>> >>> Blog: http://maharachchi.blogspot.com >>> Mobile: +94719371446 >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> Thanks & regards, >> Nirmal >> >> Senior Software Engineer- Platform Technologies Team, WSO2 Inc. >> Mobile: +94715779733 >> Blog: http://nirmalfdo.blogspot.com/ >> >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Amila Maharachchi* Senior Technical Lead WSO2, Inc.; http://wso2.com Blog: http://maharachchi.blogspot.com Mobile: +94719371446
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
