Hi Imesh, In Metrics, there are Reporters [1]. For example, DAS reporter [2] will publish metrics to a DAS server. Metrics Reporter will not publish an event for each invocation. The reporter will report periodically and we can configure that time interval.
I hope this is clear. Thanks! [1] http://dropwizard.github.io/metrics/3.1.0/manual/core/#reporters [2] https://github.com/wso2/carbon-metrics/blob/v1.2.0-M2/components/org.wso2.carbon.metrics.das.reporter/src/main/java/org/wso2/carbon/metrics/das/reporter/DASReporter.java On Tue, Dec 22, 2015 at 6:11 AM, Imesh Gunaratne <[email protected]> wrote: > Hi Isuru, > > In MetricsInterceptor, I can see multiple interceptors are collecting data > but could not figure out how they are published to a central server. It it > done by the metric manager? Would you mind explaining how this works? > > > https://github.com/wso2/product-mss/blob/v1.0.0-alpha/carbon-mss/components/org.wso2.carbon.mss/src/main/java/org/wso2/carbon/mss/metrics/MetricsInterceptor.java > > Thanks > > On Fri, Dec 18, 2015 at 2:31 PM, Isuru Perera <[email protected]> wrote: > >> Hi, >> >> In Standalone service mode, we support deploying multiple service >> instances. That's the main concern I have. If a user adds multiple >> services, the initialization step will run multiple times. Let's look at my >> suggestion in next release. >> >> I made changes and sent a PR [1]. The init() methods are synchronized and >> it will initialize only once. >> >> [1] https://github.com/wso2/product-mss/pull/86 >> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fwso2%2Fproduct-mss%2Fpull%2F86&sa=D&sntz=1&usg=AFQjCNFUEw0YxfBXCvAomqRpGjxGFJmHpA> >> >> On Fri, Dec 18, 2015 at 11:57 AM, Sagara Gunathunga <[email protected]> >> wrote: >> >>> >>> >>> On Fri, Dec 18, 2015 at 11:33 AM, Isuru Perera <[email protected]> wrote: >>> >>>> Hi all, >>>> >>>> I'm trying to refactor code and move the initialization logic out from >>>> the interceptors we have. i.e. MetricsInterceptor [1] and >>>> HTTPMonitoringInterceptor [2]. With current lifecycle method support, we >>>> can write some initialization code within the service only [3]. >>>> >>> >>> Since we are very close to GA release, let's continue with current >>> service lifecycle approach and finish refactoring of above 2 Interceptor as >>> we planed, while we can continue this discussion separately. >>> >>>> >>>> I understand that it's better to have a separate class for >>>> initialization logic. But I need to make sure that initialization runs only >>>> once. That's why I initially wrote the initialization logic at the >>>> interceptor level. The user will add interceptor only once to the MSS >>>> application [4]. >>>> >>>> If there are multiple services (as in sample [4]], we cannot ask user >>>> to initialize in each service as the initialization will run multiple >>>> times. We can solve that by changing the initialization code to run once. >>>> But I don't think that a good idea. There will be duplicate code in each >>>> service to initialize Metrics and HTTP Monitoring. >>>> >>> >>> Basically we have two deployment modes. >>> >>> 1.) Standalone service mode (aka MSS-lite) >>> >>> - In this mode we deploy single service per single application hence IMO >>> service lifecycle annotations are sufficient because initialization code >>> anyway run only one time. BTW did you find any use cases that we can't >>> cover with service LC methods under this mode ? >>> >>> 2.) OSGi server mode >>> >>> Since this mode is based on OSGi, can't we just use OSGi features such >>> as bundle activators, OSGi-service annotations[1] such as @Acitvate, >>> @Deactivate instead of inventing something new ? We already use above OSGi >>> features to register/deregister microservices, register/deregister >>> Interceptor etc. >>> >>> [1] - >>> https://kishanthan.wordpress.com/2014/03/29/using-annotation-with-osgi-declarative-services/ >>> >>> Thanks ! >>> >>> >>>> >>>> Is it possible to have lifecycle method support for the entire MSS >>>> application as well? Something similar to ServletContextListener [5]? >>>> >>>> Thanks! >>>> >>>> Best Regards, >>>> >>>> [1] >>>> https://github.com/wso2/product-mss/blob/v1.0.0-alpha/carbon-mss/components/org.wso2.carbon.mss/src/main/java/org/wso2/carbon/mss/metrics/MetricsInterceptor.java#L47-L85 >>>> [2] >>>> https://github.com/wso2/product-mss/blob/v1.0.0-alpha/carbon-mss/components/org.wso2.carbon.mss/src/main/java/org/wso2/carbon/mss/httpmonitoring/HTTPMonitoringInterceptor.java#L80-L196 >>>> [3] https://github.com/wso2/product-mss/tree/master/samples/lifecycle >>>> [4] >>>> https://github.com/wso2/product-mss/blob/v1.0.0-alpha/samples/metrics/src/main/java/org/wso2/carbon/mss/example/Application.java#L39-L40 >>>> [5] >>>> http://docs.oracle.com/javaee/6/api/javax/servlet/ServletContextListener.html >>>> >>>> >>>> >>>> On Sun, Nov 15, 2015 at 7:46 PM, Sagara Gunathunga <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Sun, Nov 15, 2015 at 7:40 PM, Afkham Azeez <[email protected]> wrote: >>>>> >>>>>> Can you fix the metric code to ise this? >>>>>> >>>>> I can work with IsuruP, still metrics/DAS code are not familiar to me. >>>>> >>>>> >>>>> Thanks ! >>>>> >>>>>> On Nov 15, 2015 6:32 PM, "Sagara Gunathunga" <[email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Nov 12, 2015 at 8:41 PM, Afkham Azeez <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Nov 12, 2015 at 5:05 AM, Sagara Gunathunga <[email protected] >>>>>>>> > wrote: >>>>>>>> >>>>>>>>> Use case >>>>>>>>> -------------- >>>>>>>>> MS F/W should support at least two bean lifecycle methods so that >>>>>>>>> one method get call during the service start-up while other one get >>>>>>>>> call >>>>>>>>> just before the service shutdown. We already have following use cases >>>>>>>>> but >>>>>>>>> this should be a much lengthy list when implementing real world use >>>>>>>>> cases. >>>>>>>>> >>>>>>>>> 1) Service stat publishing - During the service start-up, it >>>>>>>>> should be possible to initialize DAS agents and make connections, then >>>>>>>>> during the service shutdown it should be possible to terminate DAS >>>>>>>>> agents >>>>>>>>> properly and close any connection remains. >>>>>>>>> >>>>>>>> >>>>>>>> How are we doing the above now with the metrics component? >>>>>>>> >>>>>>> >>>>>>> Initially IsuruP looked for such lifecycle extension points, but >>>>>>> since it was not there it seems he has incorporated init logic into the >>>>>>> constructor of the MetricsInterceptor, although it's not nice to mix >>>>>>> separate aspect together technically it worked. Further there was no >>>>>>> proper >>>>>>> place to call any cleaning code during server shutdown. >>>>>>> >>>>>>> Thanks ! >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> 2.) Metadata publishing - During the service start-up, it should >>>>>>>>> be possible to publish service and endpoint metadata into a >>>>>>>>> centralized >>>>>>>>> metadata repository such as G-Reg and during the service shutdown it >>>>>>>>> should >>>>>>>>> be possible to remove/deactivate service or endpoint metadata on >>>>>>>>> metadata >>>>>>>>> repository. >>>>>>>>> >>>>>>>>> 3.) Handle connection establishment and termination for data >>>>>>>>> sources such as RSBMS, LDAPs , legacy systems etc. >>>>>>>>> >>>>>>>>> >>>>>>>>> Solution >>>>>>>>> -------------- >>>>>>>>> >>>>>>>>> Instead of introducing our own proprietary approaches we could use >>>>>>>>> @PostConstruct[1] and @PreDestroy[2] annotations available with JDK. >>>>>>>>> Users just need to annotate their init and termination methods as >>>>>>>>> follows. >>>>>>>>> Additionally this is a natural choice for those who familiar with >>>>>>>>> JAX-WS/JAX-RS programming models where above annotation are used for >>>>>>>>> same >>>>>>>>> purpose. >>>>>>>>> >>>>>>>>> @PostConstruct >>>>>>>>> public void init() { >>>>>>>>> LOG.info("Helloworld :: calling PostConstruct method"); >>>>>>>>> } >>>>>>>>> >>>>>>>>> @PreDestroy >>>>>>>>> public void close() { >>>>>>>>> LOG.info("Helloworld :: calling PreDestroy method"); >>>>>>>>> } >>>>>>>>> >>>>>>>>> >>>>>>>>> I have added above 2 annotation support to MS trunk, please refer >>>>>>>>> following working sample[3]. >>>>>>>>> >>>>>>>>> >>>>>>>>> @IsuruP , since we have service lifecycle support now, we need to >>>>>>>>> refactor your analytics sample to use proper annotations and it will >>>>>>>>> become >>>>>>>>> a real world sample as well, [3] is too simple to demonstrate real >>>>>>>>> world >>>>>>>>> use cases. >>>>>>>>> >>>>>>>>> >>>>>>>>> [1] - >>>>>>>>> https://docs.oracle.com/javaee/5/api/javax/annotation/PostConstruct.html >>>>>>>>> [2] - >>>>>>>>> https://docs.oracle.com/javaee/5/api/javax/annotation/PreDestroy.html >>>>>>>>> [3] - >>>>>>>>> https://github.com/wso2/product-mss/tree/master/samples/lifecycle >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks ! >>>>>>>>> -- >>>>>>>>> Sagara Gunathunga >>>>>>>>> >>>>>>>>> Architect; WSO2, Inc.; http://wso2.com >>>>>>>>> V.P Apache Web Services; http://ws.apache.org/ >>>>>>>>> Linkedin; http://www.linkedin.com/in/ssagara >>>>>>>>> Blog ; http://ssagara.blogspot.com >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> *Afkham Azeez* >>>>>>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>>>>>> Member; Apache Software Foundation; http://www.apache.org/ >>>>>>>> * <http://www.apache.org/>* >>>>>>>> *email: **[email protected]* <[email protected]> >>>>>>>> * cell: +94 77 3320919 <%2B94%2077%203320919>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 >>>>>>>> <http://lk.linkedin.com/in/afkhamazeez>* >>>>>>>> >>>>>>>> *Lean . Enterprise . Middleware* >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Sagara Gunathunga >>>>>>> >>>>>>> Architect; WSO2, Inc.; http://wso2.com >>>>>>> V.P Apache Web Services; http://ws.apache.org/ >>>>>>> Linkedin; http://www.linkedin.com/in/ssagara >>>>>>> Blog ; http://ssagara.blogspot.com >>>>>>> >>>>>>> >>>>> >>>>> >>>>> -- >>>>> Sagara Gunathunga >>>>> >>>>> Architect; WSO2, Inc.; http://wso2.com >>>>> V.P Apache Web Services; http://ws.apache.org/ >>>>> Linkedin; http://www.linkedin.com/in/ssagara >>>>> Blog ; http://ssagara.blogspot.com >>>>> >>>>> >>>> >>>> >>>> -- >>>> Isuru Perera >>>> Associate Technical Lead | WSO2, Inc. | http://wso2.com/ >>>> Lean . Enterprise . Middleware >>>> >>>> about.me/chrishantha >>>> Contact: +IsuruPereraWSO2 >>>> <https://www.google.com/+IsuruPereraWSO2/about> >>>> >>> >>> >>> >>> -- >>> Sagara Gunathunga >>> >>> Architect; WSO2, Inc.; http://wso2.com >>> V.P Apache Web Services; http://ws.apache.org/ >>> Linkedin; http://www.linkedin.com/in/ssagara >>> Blog ; http://ssagara.blogspot.com >>> >>> >> >> >> -- >> Isuru Perera >> Associate Technical Lead | WSO2, Inc. | http://wso2.com/ >> Lean . Enterprise . Middleware >> >> about.me/chrishantha >> Contact: +IsuruPereraWSO2 <https://www.google.com/+IsuruPereraWSO2/about> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Imesh Gunaratne* > Senior Technical Lead > WSO2 Inc: http://wso2.com > T: +94 11 214 5345 M: +94 77 374 2057 > W: http://imesh.gunaratne.org > Lean . Enterprise . Middleware > > -- Isuru Perera Associate Technical Lead | WSO2, Inc. | http://wso2.com/ Lean . Enterprise . Middleware about.me/chrishantha Contact: +IsuruPereraWSO2 <https://www.google.com/+IsuruPereraWSO2/about>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
