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. 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
