Sanjiva Weerawarana wrote: > If we do it the way Deepal had worked on a while ago, the downtime is > VERY low. Basically, what we need to do is to mark the AxisService as > "old" (or inactive) and then that immediately stops new messages from > being delivered to it. Any already dispatched service is not at all > affected - as the handler chain etc. is already computed and in any > case we're not changing that AxisService instance. The new AxisService > object representing the updated service can then be deployed by making > that be what's found by service lookup. In other words, if we do this > by locking AxisConfig then the downtime is basically time of object > lock + copying a few pointers. Once all messages that are running > "finish", the old AxisService will just get GC'ed. > > Hmmm clearly there must be some bug in that logic; its too simple. :), You must be kidding right :)
Yes a few bugs, first if the service create any connection like DB or file and put into ConFigCTX then those will not be removed when we do the undeployment since service does not know that. Second, if they add any properties to ConFigCtx then the same thing happens. Third it is hard to detect when to finish the current message processing, because request follows different invocation depending on the MEP. Forth if the service uses something like RM, then we are not going to inform RM about that, so those state will remain there. Fifth based on where we have lib, we load classes various class loaders, so at the deployment time we can not 100% guarantee that we are going to unload all the classes. There may be some other, which did not come into my mind..... Thanks, Deepal > > Sanjiva. > > On Sun, Aug 30, 2009 at 1:16 PM, Afkham Azeez <afk...@gmail.com > <mailto:afk...@gmail.com>> wrote: > > Simply deactivating-redeploying-activating is not the ideal > solution. It should be; > > > maintenace-mode(service_foo)->redeploy(service_foo)->normal-mode(service_foo) > > In maintenance mode, a service will not accept new requests, but > will complete servicing existing requests. So, there is a > difference between deactivating a service & putting it into > maintenance-mode, unless deactivated services will complete the > requests being processed. > > However, there will be a small downtime for this service. > > Azeez > > > On Sun, Aug 30, 2009 at 4:02 AM, Deepal jayasinghe > <deep...@gmail.com <mailto:deep...@gmail.com>> wrote: > > > > > > > > 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. > It is doable, and in fact I have done that, but did not commit my > changes, since it was just for fun :). > In AxisService you have a method called activate/inactivate, > when you > inactive a service system does not take any more request to > that service > (will throw an exception saying service not found) and will > process all > the current messages. Then, you need call the deployment engine to > update the new service (Deployment engine has a method to load a > particular services). Then you back in business. > > Thanks, > Deepal > > > > > -- > Thanks > Afkham Azeez > > Blog: http://afkham.org > Developer Portal: http://www.wso2.org > WSAS Blog: http://wso2wsas.blogspot.com > Company: http://wso2.com > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760 > > > > > -- > 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/ -- Thank you! http://blogs.deepal.org http://deepal.org
