On Thu, Aug 27, 2009 at 10:06 AM, Ruwan Linton <ruwan.lin...@gmail.com>wrote:
> Hi devs, > > I am trying to implement the Hot deployment and Hot update of the synapse > artifacts, and realized that there are some issues; I first thought of > writing our own deployment behaviour because we wanted some conditions to be > checked on the hot update case undeployment of the artifacts. > > Let me first describe how Hot update works in axis2, correct me if I am > wrong but from what I have figured out so far, axis2 repository listener > task calls unDeploy method of the deployer implementation first and then > calls the deploy method again to deploy the artifact with the changes. > > So this approach has two issues, > > 1. There is a considerable downtime of the artifact which is being hot > updated > 2. There is no means of knowing the case where the undeploy method > being called, for example synapse needs to have a main sequence for it to > operate properly, so synapse has to force the user to not to undeploy the > main sequence while it should allow the user to hot update it. > > I propose adding a update method to the Deployer interface or passing the > state as an argument, we could use the DeploymentFileData class to provide > the operation, but that doesn't resolve the issue because the undeploy > method has a String file name as its argument, so this canot be fixed > without an API change in the deployer implementation. > > Being said the above I can implement this in Synapse, but since we had huge > debates earlier on writing stuff on synapse replacing axis2 stuff just > because they do not fit into synapse without letting the axis2 community > know about those, I thought of proposing this to the axis2 as well. > > WDYT? > > Or may be I am missign something which can resolve the above 2 issues, in > which case please be kind enough to point me to the behaviour that I should > be using.. :-) I went through the deployment engine code and it seems bit complicated and can not solve without changing Deployer interface. Let me put this suggestion if it works for you :). At the undeploy method you get the file name. Then you can check whether this file exists. if not exist this is only an undeployment so you do the undeployment if exists then this is a update, you keep this entry in your deployer. Now at the deploy method if there is an entry you do an update and if not do a fresh deployments. Anyway I think, writing a synapse deployer would be a correct long term solution since you can customise it purely for synapse needs. thanks, Amila. > > > Thanks, > Ruwan > > -- > Ruwan Linton > Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb > WSO2 Inc.; http://wso2.org > email: ru...@wso2.com; cell: +94 77 341 3097 > blog: http://ruwansblog.blogspot.com > -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/
