Hi Nandika, On Thu, Mar 24, 2016 at 7:43 PM, Nandika Jayawardana <[email protected]> wrote:
> What about providing a REST API from each node of the cluster which can be > used to query deployed artifact information in addition to JMS publishing. > There will be admin services later on that will provide artifact information, but we need to see how usable that is to understand failed artifact deployments. Because users will need to poll and pull data from each node periodically to find out whether the artifact deployment is successful at that moment. Here, what we are proposing is a push model where all the nodes will push its whenever an artifact is deployed. An interested consumer can listen for these events and take actions as required. Thanks, KasunG > Regards > Nandika > > On Thu, Mar 24, 2016 at 3:45 PM, KasunG Gajasinghe <[email protected]> > wrote: > >> >> >> On Thu, Mar 24, 2016 at 3:23 PM, Sameera Jayasoma <[email protected]> >> wrote: >> >>> Btw, who are the consumers of these messages? User can develop their own >>> tools to monitor artifact deployment. >>> >>> We also can come with CEP query to analyze whether the artifact >>> deployment happened successfully in a cluster and display this information >>> in a dashboard. We can come up with a DAS C-App. >>> >> >> +1 for the idea. >> >> The initial phase that is described in this thread is to provide the >> deployment status notifications. Coordination will be the next step on top >> of this. >> >> >> >>> >>> Thanks, >>> Sameera. >>> >>> On Wed, Mar 23, 2016 at 2:24 PM, Sameera Jayasoma <[email protected]> >>> wrote: >>> >>>> I believe we need both here. >>>> >>>> In JMS case, we need to publish events to a topic rather than a queue. >>>> >>>> Thanks, >>>> Sameera. >>>> >>>> On Wed, Mar 23, 2016 at 2:02 PM, Srinath Perera <[email protected]> >>>> wrote: >>>> >>>>> Kasun, I would go with JMS as it gives event persistence and you will >>>>> not loose the events even if listener is restarted. >>>>> >>>>> --Srinath. >>>>> >>>>> On Wed, Mar 23, 2016 at 10:45 AM, KasunG Gajasinghe <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Given several issues we discovered with automatic artifact >>>>>> synchronization with DepSync in C4, we have discussed how to approach >>>>>> this >>>>>> problem in C5. >>>>>> >>>>>> We are thinking of not doing the automated artifact synchronization >>>>>> in C5. Rather, users should use their own mechanism to synchronize the >>>>>> artifacts across a cluster. Common approaches are RSync as a cron job and >>>>>> shell scripts. >>>>>> >>>>>> But, it is vital to know the artifact deployment status of the nodes >>>>>> in the entire cluster from a central place. For that, we are providing >>>>>> this >>>>>> deployment coordination feature. There will be two ways to use this. >>>>>> >>>>>> 1. JMS based publishing - the deployment status will be published by >>>>>> each node to a jms topic/queue >>>>>> >>>>>> 2. Log based publishing - publish the logs by using a syslog appender >>>>>> [1] or our own custom appender to a central location. >>>>>> >>>>>> The log publishing may not be limited to just the deployment >>>>>> coordination. In a containerized deployment, the carbon products will run >>>>>> in disposable containers. But sometimes, the logs need to be backed up >>>>>> for >>>>>> later reference. This will help with that. >>>>>> >>>>>> Any thoughts on this matter? >>>>>> >>>>>> [1] >>>>>> https://logging.apache.org/log4j/2.x/manual/appenders.html#SyslogAppender >>>>>> >>>>>> Thanks, >>>>>> KasunG >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ~~--~~ >>>>>> Sending this mail via my phone. Do excuse any typo or short replies >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> ============================ >>>>> Srinath Perera, Ph.D. >>>>> http://people.apache.org/~hemapani/ >>>>> http://srinathsview.blogspot.com/ >>>>> >>>> >>>> >>>> >>>> -- >>>> Sameera Jayasoma, >>>> Software Architect, >>>> >>>> WSO2, Inc. (http://wso2.com) >>>> email: [email protected] >>>> blog: http://blog.sameera.org >>>> twitter: https://twitter.com/sameerajayasoma >>>> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections >>>> Mobile: 0094776364456 >>>> >>>> Lean . Enterprise . Middleware >>>> >>>> >>> >>> >>> -- >>> Sameera Jayasoma, >>> Software Architect, >>> >>> WSO2, Inc. (http://wso2.com) >>> email: [email protected] >>> blog: http://blog.sameera.org >>> twitter: https://twitter.com/sameerajayasoma >>> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections >>> Mobile: 0094776364456 >>> >>> Lean . Enterprise . Middleware >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> *Kasun Gajasinghe*Senior Software Engineer, WSO2 Inc. >> email: kasung AT spamfree wso2.com >> linked-in: http://lk.linkedin.com/in/gajasinghe >> blog: http://kasunbg.org >> >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Nandika Jayawardana > WSO2 Inc ; http://wso2.com > lean.enterprise.middleware > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Kasun Gajasinghe*Senior Software Engineer, WSO2 Inc. email: kasung AT spamfree wso2.com linked-in: http://lk.linkedin.com/in/gajasinghe blog: http://kasunbg.org
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
