Hi Thilini please find my comments inline
On Mon, Feb 17, 2014 at 8:08 PM, Thilini Ishaka <[email protected]> wrote: > > > Hi Pulasthi, > > On Tue, Feb 18, 2014 at 5:36 AM, Pulasthi Supun <[email protected]> wrote: > >> Hi All, >> >> In BPS when we directly copy a new zip ( which is identified by the >> md5sum of the zip file ) file of an existing BPEL process to >> /repository/deployment/server/bpel folder this will be picked up as an new >> version of the process and the existing process will be kept as a retired >> process ( correct me if i am wrong ). To my understanding this is required >> since there may be process instances that my be running on the older >> version of the process which is ok. But when we do not have any instances >> associated with an particular process that we are going to retire because >> there is a new version, shouldn't we be able to automatically remove the >> older version?. >> > Prior to the deployment of the updated package, you can check whether > there are any active instances belongs to the existing package. (Filter by > instance status in instance information page) If no active instances, you > can undeploy the existing package first and deploy the newer package. This > can be used as a best practice. > Yes undeploying the older version does work properly through UI, but when the deployment is done through a puppet script it is not possible to follow this process. that is why i suggested this. The requirement came to mind because of the following scenario. 1. Assume a setup that is maintained through puppet scripts. 2. After a certain period of time puppet runs to add all the new changes to the setup and clean the manual changes that need to be removed. 3. The build process is done through Jenkins and at every puppet run this will create a new process zip file for BPEL processes. 4. This will result in a new version being created on every puppet run and older versions will keep accumulating on the system. If there are several BPEL process this will be a problem. This may not be a problem when the development stage is completed. I feel that this is generic requirement that would make setup process a little more clean. I am not aware of the amount of work that would be needed to achieve this so i am not sure if its worth the trouble. > > >> is there a reason to why this is not handled?. >> >> The accumulation of such process can lead to out of memory errors in >> production setups . The new cleanup tool that was introduced with the BPS >> 3.2.0 release does give a manual solution to this but wouldn't it be better >> handle this within the code itself. >> > Why do you say, this as a manual solution? What are your suggestions? > By manual process i only meant the script has to be executed from time to time :) by DevOps . I understand that this would be the best way to clean up old instances i am only suggesting that when a new version is deployed we could check if there are any instances associated with it and if there are none we can remove that version. Regards, Pulasthi This is an admin/dev-ops task, running the package cleanup script is more > easier as well as a faster way to cleanup retired packages and unwanted > instances. > > Thanks > Thilini > >> >> WDYT? >> >> Regards, >> Pulasthi >> >> >> >> -- >> -- >> Pulasthi Supun >> Software Engineer; WSO2 Inc.; http://wso2.com, >> Email: [email protected] >> Mobile: +94 (71) 9258281 >> Blog : http://pulasthisupun.blogspot.com/ >> Git hub profile: https://github.com/pulasthi >> > > > > -- > Thilini Ishaka > Senior Software Engineer > Phone: +94 11 214 5345 > WSO2 Inc. http://wso2.com > > blog: thiliniishaka.blogspot.com > linkedin: http://lk.linkedin.com/in/thiliniishaka > twitter: https://twitter.com/#!/ThiliniIsh > -- -- Pulasthi Supun Software Engineer; WSO2 Inc.; http://wso2.com, Email: [email protected] Mobile: +94 (71) 9258281 Blog : http://pulasthisupun.blogspot.com/ Git hub profile: https://github.com/pulasthi
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
