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
