I forgot to mention another point I've been thinking of - even with hot deployment turned off, what we have by default is a "scan and deploy at startup" type model. For example, if someone makes a mistake with file permissions a particular service may not (silently) get deployed.
IMO we also need to support a more locked-down model similar to what was done for the URL repo code with services.list. Basically to manually write down the list of services to be deployed (in the order that's listed even) instead of discovering what's around and deploying them once. I'm not at all suggesting losing any functionality we have but rather to maybe support services.list in all cases. IIRC that only works (out of necessity) for URL repos as there was no way to get a list then. Now of course we'd just make it an atom feed instead of inventing our own silly little format ... Sanjiva. On Sun, Aug 30, 2009 at 8:15 AM, Sanjiva Weerawarana <sanj...@opensource.lk>wrote: > On Thu, Aug 27, 2009 at 8:47 PM, Andreas Veithen < > andreas.veit...@gmail.com> wrote: > >> >> >> > In Axis2, specially in production hot deployment is not something people >> > are going to use regularly. So downtown or hot-update is not an big >> > issues (rather they will turn off both hot-deployment and hot-update) >> >> Does the Axis2 deployment mechanism lack this kind of features because >> people don't use it regularly, or do people not use it regularly >> because it lacks these features? > > > In my experience so far, people do use / leave hot deployment around but > the deployment processes effectively disable it. That is, in no production > setting is the developer allowed to update the config of a running server by > logging into it :). In one case I know of someone who's updating the > (Synapse) system config multiple times a day but does it by putting their > servers into "service mode" in a round-robin fashion but that's the type of > care someone must take to "hot update" a production system. In service mode > the server doesn't accept any more messages but processes the messages that > were in flight before doing system updates. So effectively he brings a node > in a cluster down without affecting service response. However, it does > result in a period of time where the servers have different versions of > stuff deployed (I think). > > However, for developers this is very useful ... its like being able to edit > a JSP and just refresh the page. Imagine if you had to redeploy the war file > to get that to work?! > > IMO the deployer interface needs an update() method which the deployment > logic calls after it determines (somehow) that the service needs to be > updated. If we're changing the signature then we might as well do ti right > rather than hacking it in (by passing a filename). > > Then there's the question of how to do the update - ideal is to let > messages that are already being processed be processed by the still active > version and to direct new messages to the new version. I'm not sure that's > implementable though .. or it would require one to bring that concept into > dispatchers etc. to do the right thing. Ideal is for it to be burnt into the > AxisConfig but that's a *huge* change. If its considered a developer level > feature then the current style is ok - just yank the old one and put the new > one in. > > So to answer your question - IMO its because its VERY hard to hot update a > system and not have weird/inconsistent behavior. If you absolutely need 24x7 > operation with zero (scheduled) downtime then of course you need to do > something like what I explained above and then clearly understand the issues > related to different nodes having different versions of the service around. > Its much easier to have a scheduled downtime. > > Sanjiva. > -- > Sanjiva Weerawarana, Ph.D. > Founder, Director & Chief Scientist; Lanka Software Foundation; > http://www.opensource.lk/ > Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/ > Member; Apache Software Foundation; http://www.apache.org/ > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ > > Blog: http://sanjiva.weerawarana.org/ > -- Sanjiva Weerawarana, Ph.D. Founder, Director & Chief Scientist; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/
