Hi Isuru, You are correct. Hot-deployment and Hot-update is working for CAR files. Then we don't need any additional coding to support artifact synchronization across cluster.
Thanks, Chanaka On Tue, Apr 7, 2015 at 2:40 PM, Isuru Udana <[email protected]> wrote: > Hi Chanaka, > > On Tue, Apr 7, 2015 at 2:36 PM, Chanaka Fernando <[email protected]> > wrote: > >> Another aspect of this feature is how it is working in a clustered >> environment. If we are going to save the changes in to memory, then these >> changes will not be reflected in other nodes (Ex: worker nodes). This can >> be overcome by saving the changes to the CAR file and redeploy the CAR >> file. AFAIK, In the current implementation, CAR deployer is not checking >> for changes of the CAR file for redeployment. >> > I thought we already have this. We do support hot-deployment for CAR > files. I think hot-update is also there. > >> We need to implement a similar feature to synapse artifact deployment >> (where it checks for file changes with a timer) for the CAR deployment as >> well. >> >> Thanks, >> Chanaka >> >> On Mon, Apr 6, 2015 at 2:05 PM, Chanaka Fernando <[email protected]> >> wrote: >> >>> Hi All, >>> >>> [Moving to architecture] >>> >>> Thanks everyone for the feedback. According to your suggestions, we will >>> go with the following approach to implement this incrementally. >>> >>> 1) Save the changes done through the Management Console in to memory >>> without saving them in the file system in the deployment directory. This >>> will make sure that users will not get any conflicting issues when >>> restarting the server. >>> >>> 2) Persist the changes to CAR file to save the changes after server >>> restart. This will make sure we have a consistent story in the management >>> console when changing artifacts coming from CAR or not from CAR file. >>> >>> Thanks, >>> Chanaka >>> >>> On Fri, Apr 3, 2015 at 3:55 PM, Ravi Undupitiya <[email protected]> wrote: >>> >>>> I agree with Malaka and his reasoning. But users might expect the >>>> changes they made through UI to be there after a server restart - in that >>>> case we should persist changes in CApp. >>>> >>>> IMO the biggest benefit of this whatever we decide is not persisting >>>> artifacts in synapse-configs folder since this almost always causes next >>>> CApp upload to conflict and not deploy properly. >>>> >>>> >>>> >>>> >>>> On Thu, Apr 2, 2015 at 10:54 PM, Isuru Udana <[email protected]> wrote: >>>> >>>>> Hi All, >>>>> >>>>> On Thu, Apr 2, 2015 at 7:19 PM, Malaka Silva <[email protected]> wrote: >>>>> >>>>>> Hi Chanaka, >>>>>> >>>>>> My comments in blue color >>>>>> >>>>>> On Thu, Apr 2, 2015 at 4:25 PM, Chanaka Fernando <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> We are planning to implement $subject with the ESB 4.9.0 release (or >>>>>>> later version). I have created the redmine [1]. Please add your >>>>>>> suggestions. >>>>>>> >>>>>>> With the existing functionality, once we deployed an artifact using >>>>>>> a CAR file we have the following limitations. >>>>>>> >>>>>>> 1) We can't differentiate from management console whether the >>>>>>> artifact comes from a CAR file or not. >>>>>>> >>>>>>> 2) If the user changes an artifact deployed from a CAR file, that is >>>>>>> saved in to the file system in a separate location. These changes are >>>>>>> not >>>>>>> persisted in the CAR file >>>>>>> >>>>>>> 3) Once the server is restarted with this changes in place, it will >>>>>>> throw exceptions since there is an artifact with the same name. >>>>>>> >>>>>>> We need to overcome this issue and come up with a proper solution to >>>>>>> address these issues. We can construct a solution with the below >>>>>>> approach. >>>>>>> >>>>>>> - Identify whether the artifact is coming from a CAR file or not. >>>>>>> >>>>>>> >>>>>>> - If it is coming from a CAR file and if it is changed from the >>>>>>> management console, we can have 2 approaches. >>>>>>> >>>>>>> 1. Persist the changes in memory without saving them in to >>>>>>> deployment directory. >>>>>>> >>>>>> +1 If an user want's to check something real quick they can do >>>>>> this. When the server restarts it'll be ignored. If when want to keep the >>>>>> changes need to change the car and redeploy. >>>>>> >>>>>>> 2. Persist the changes in to CAR file (This would be the ideal >>>>>>> solution) >>>>>>> >>>>>> I really don't agree with this. Users who use cars maintain the >>>>>> project in SVN or GIT. If we save the changes directly from UI >>>>>> subversioned >>>>>> copy gets outdated. WDYT? >>>>>> >>>>> IMO this is a very useful improvement if we can do. I do not think we >>>>> need worry too much on external factors like where the car is placed (svn >>>>> etc.). What we really matters to us is the consistency. >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> [1] https://redmine.wso2.com/issues/3837 >>>>>>> >>>>>>> -- >>>>>>> -- >>>>>>> Chanaka Fernando >>>>>>> Technical Lead >>>>>>> WSO2, Inc.; http://wso2.com >>>>>>> lean.enterprise.middleware >>>>>>> >>>>>>> mobile: +94 773337238 >>>>>>> Blog : http://soatutorials.blogspot.com >>>>>>> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0 >>>>>>> Twitter:https://twitter.com/chanakaudaya >>>>>>> Wordpress:http://chanakaudaya.wordpress.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Best Regards, >>>>>> >>>>>> Malaka Silva >>>>>> Senior Tech Lead >>>>>> M: +94 777 219 791 >>>>>> Tel : 94 11 214 5345 >>>>>> Fax :94 11 2145300 >>>>>> Skype : malaka.sampath.silva >>>>>> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 >>>>>> Blog : http://mrmalakasilva.blogspot.com/ >>>>>> >>>>>> WSO2, Inc. >>>>>> lean . enterprise . middleware >>>>>> http://www.wso2.com/ >>>>>> http://www.wso2.com/about/team/malaka-silva/ >>>>>> <http://wso2.com/about/team/malaka-silva/> >>>>>> >>>>>> Save a tree -Conserve nature & Save the world for your future. Print >>>>>> this email only if it is absolutely necessary. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> *Isuru Udana* >>>>> Senior >>>>> *Software Engineer* >>>>> WSO2 Inc.; http://wso2.com >>>>> email: [email protected] cell: +94 77 3791887 >>>>> blog: http://mytecheye.blogspot.com/ >>>>> twitter: http://twitter.com/isudana >>>>> >>>> >>>> >>>> >>>> -- >>>> *Ravi Undupitiya* >>>> Senior Software Engineer; WSO2 http://wso2.com >>>> >>>> >>>> *E-mail: [email protected] <http://wso2.com>**M: **+94 772 930 712 >>>> <%2B94%C2%A0772%20930%20712>* >>>> >>>> Lean . Enterprise . Middleware >>>> >>> >>> >>> >>> -- >>> -- >>> Chanaka Fernando >>> Technical Lead >>> WSO2, Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> mobile: +94 773337238 >>> Blog : http://soatutorials.blogspot.com >>> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0 >>> Twitter:https://twitter.com/chanakaudaya >>> Wordpress:http://chanakaudaya.wordpress.com >>> >>> >>> >>> >> >> >> -- >> -- >> Chanaka Fernando >> Technical Lead >> WSO2, Inc.; http://wso2.com >> lean.enterprise.middleware >> >> mobile: +94 773337238 >> Blog : http://soatutorials.blogspot.com >> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0 >> Twitter:https://twitter.com/chanakaudaya >> Wordpress:http://chanakaudaya.wordpress.com >> >> >> >> > > > -- > *Isuru Udana* > Senior > *Software Engineer* > WSO2 Inc.; http://wso2.com > email: [email protected] cell: +94 77 3791887 > blog: http://mytecheye.blogspot.com/ > twitter: http://twitter.com/isudana > -- -- Chanaka Fernando Technical Lead WSO2, Inc.; http://wso2.com lean.enterprise.middleware mobile: +94 773337238 Blog : http://soatutorials.blogspot.com LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0 Twitter:https://twitter.com/chanakaudaya Wordpress:http://chanakaudaya.wordpress.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
