axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
Subject Re: [AXIS2][Deployement] Hot Deployement techniques
Date Fri, 08 Oct 2004 15:23:14 GMT

On Fri, 8 Oct 2004 07:54:48 +0600, Sanjiva Weerawarana 
<sanjiva@opensource.lk> wrote:
 > To me, hot deployment is a feature for developer convenience
 > and not really for production. For developers the race condition
 > problem is not a likely thing IMO - do you agree?
 >

agreed, mostly. I've been burned in production systems where saved 
session state was still in a different classloader; it didnt purge stuff.

<gratuitous-product-placement producturl="http://smartfrog.org">

I actually added axis deploy and configure in smartfrog last month, as 
part of a grid deployment prototype discussed here:-

http://forge.gridforum.org/projects/cddlm-wg/document/service-API-paper/en/1
http://forge.gridforum.org/projects/cddlm-wg/document/service-API-presentation/en/2

What you do is explicity send a deploy request to the system (originally 
RMI, in the proto SOAP),
which includes a list of URLs for the classloader to search for when 
dynamically downloading classes. So you dont even need to have the stuff 
on the target machine, just hosted on a visible web server (and signed 
by a certificate your runtime likes). To update something you undeploy 
that bit of the graph of deployed things, and deploy a replacement, 
perhaps with a new/updated list of JAR files.

It is pretty fiddly still to get a deployment descriptor up and running, 
as you are trying to configure many things in one go (jetty, axis, ...), 
but once it is up and running it works pretty well for doing full 
restarts of complex systems. And lets face it, apart from the lead time 
hit, restarts are the cleanest.

</gratuitous-product-placement producturl="http://smartfrog.org">


 > In production, there's indeed one scenario where this could
 > occur: if a hosting kind of place allows people to hot
 > deploy services .. but in that case the "hot" deployment will
 > occur via some remote protocol (like an HTTP POST uploading
 > the aar file, for example) and we could make sure that whatever
 > we implement for such scenarios do follow some locking to
 > prevent race conditions. Others could screw it up, but we can
 > document saying that's a requirement of the hot deployment
 > engine.
 >
 > The other scenario is at server startup time the system loads
 > up everything in the deployed services directory (without expecting
 > everything to be listed in server-config.wsdd like now that is).
 > There too I guess there's potential for race conditions but again
 > I don't see it as very likely.
 >
 > In any case, we don't need to invent here. Deepal, were you able
 > to find out what Tomcat does? What's good enough for Tomcat is
 > good enough for us I'd say!

Tomcat loads stuff in its directories, then when you send it a jmx or 
HTTP  request it loads new JARs. At least, that is how it has worked for 
me. But then there are JSP pages, which are special. I think they get 
recompiled and reloaded if they change.


 > BTW I'm definitely -1 on making Axis2 JDK 1.5 specific :-).

Nobody on gump was very happy this morning when I accidentally made 
Ant1.7 JDK-specific either :)

JDK1.5 is quite profound in terms of language changes, the most 
significant since the 1.0 -> 1.1 transition, and that makes a big 
difference in coding. It reminds me of when C++ added templates. At the 
same time, it will be a long time for the migration to happen, and, 
realistically, some code won't go. Its just that tomcat5.5 and the new 
EJB stuff is going to JDK1.5 for all the annotation stuff, so you can be 
sure that all the new libraries are present too. If we had to track 
those specs then we'd have to move up too, but I guess that is a matter 
for the JAX-RPC wg.

-steve

Mime
View raw message