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/
