Hi, As already mentioned OSGI dependencies will not work in a distributed setup. Instead I prefer a event based mechanism.
On Tue, Mar 10, 2015 at 12:06 PM, Rajkumar Rajaratnam <rajkum...@wso2.com> wrote: > s/same machine/single JVM > > On Tue, Mar 10, 2015 at 11:51 AM, Rajkumar Rajaratnam <rajkum...@wso2.com> > wrote: > >> Hi Isuru, >> >> Yes this happening when we are creating monitors by reading application >> topology. And I guess enforcing OSGi dependencies among components will >> completely break the distributed setup. Since components are not running in >> the same machine >> AS will be waiting forever for CC service to become >> active. >> >> As you said, it is better to go with event based solution. >> >> Thanks. >> >> On Tue, Mar 10, 2015 at 11:45 AM, Isuru Haththotuwa <isu...@apache.org> >> wrote: >> >>> Hi Raj, >>> >>> On Tue, Mar 10, 2015 at 11:31 AM, Rajkumar Rajaratnam < >>> rajkum...@wso2.com> wrote: >>> >>>> Hi Devs, >>>> >>>> I have found issues in stratos server restart. >>>> >>>> As you know we don't persist monitors. We read the topology and create >>>> monitors when we restart the Stratos. While we are creating monitors, we >>>> need to communicate with cloud controller service in-order to do things >>>> like getting deployment policy, network partitions, validating them and so >>>> on. In the single machine setup, AS component is starting before CC. So >>>> when AS tries to communicate with CC, it is failing >> ultimately monitor >>>> creation will fail. >>>> >>> Does this issue come in when we are creating Application Monitors? AS >>> starts before CC -> AS tries to restore the Application Monitors from the >>> local Applications Toplogy -> tries to communicate with CC -> leads to the >>> issue? >>> >>>> >>>> What would be solution here? Is there any way to enforce start up >>>> orders between components? I know we can use OSGI dependencies to enforce >>>> such order. We can make AS component to wait until CC component is >>>> activated. But will that solve the problem in distributed setup? >>>> >>> AFAIK enforcing the bundle startup order will not solve this in a >>> distributed setup. How about an event related solution? CC (or any other >>> related component) sending an event to say that it is started? To avoid the >>> deadlock in an event loss, maybe we can add a timeout as well. >>> >>>> >>>> Please share your thoughts on this. >>>> >>>> Thanks. >>>> >>>> -- >>>> Rajkumar Rajaratnam >>>> Committer & PMC Member, Apache Stratos >>>> Software Engineer, WSO2 >>>> >>>> Mobile : +94777568639 >>>> Blog : rajkumarr.com >>>> >>>> -- >>>> <http://rajkumarr.com> >>>> <http://rajkumarr.com> >>>> Thanks and Regards, >>>> >>>> Isuru H. >>>> <http://rajkumarr.com> >>>> +94 716 358 048 <http://rajkumarr.com>* <http://wso2.com/>* >>>> >>>> >>>> * <http://wso2.com/>* >>>> >>>> >>>> >> >> >> -- >> Rajkumar Rajaratnam >> Committer & PMC Member, Apache Stratos >> Software Engineer, WSO2 >> >> Mobile : +94777568639 >> Blog : rajkumarr.com >> > > > > -- > Rajkumar Rajaratnam > Committer & PMC Member, Apache Stratos > Software Engineer, WSO2 > > Mobile : +94777568639 > Blog : rajkumarr.com > -- Udara Liyanage Software Engineer WSO2, Inc.: http://wso2.com lean. enterprise. middleware web: http://udaraliyanage.wordpress.com phone: +94 71 443 6897
