tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From pkriens <Peter.Kri...@aQute.biz>
Subject Re: Osgifing Tomcat
Date Mon, 28 Apr 2008 06:07:46 GMT

The way the dynamics work in OSGi is only partly classloading. In the HTTP
examples, we have defined an HttpService where you register a servlet. When
a bundle (OSGi JAR) is started, it registers a servlet with the http
service. When it is stopped, the Http Service detects this and removes the
mapping. When you update the bundle, the bundle is first stopped,
automatically cleaning up the servlet registration. Then the code is
replaced though the old code remains in memory because other bundles could
still import packages from this bundle. This remains until the packages are
"refreshed". This will create a dependency graph of all affected bundles,
stop these and start them again with a new class loader.

So there is no "magic". The key trick is that bundles have their own
classloader and we can start and activate them as well as stop them at any
moment in time. Obviously this works only if you make your bundles proper
modules with loose coupling. If classes are shared between bundles willy
nilly refreshing the packages will be a full restart.

Neither is it of course completely gapless. However, many, many people have
installations where they replace their bundles with servlets on the fly
because the Http server rarely if ever has a dependency on the application
code.

Kind regards,

   Peter Kriens




Costin Manolache-2 wrote:
> 
> On Fri, Apr 25, 2008 at 12:49 AM, David Jencks <david_jencks@yahoo.com>
> wrote:
>>
>>  On Apr 24, 2008, at 11:11 PM, Henri Gomez wrote:
>>
>>
>> >
>> > > I've heard various claims of this nature from osgi zealots, but when
>> > > talking to apparent experts the only things resembling this they
>> seemed
>> to
>> > > know about were grad student experiments that did not have production
>> use as
>> > > even a far-in-the-future goal.  Do you know of any actual examples of
>> this
>> > > kind of behavior that actually work under load?
>> > >
>> >
>> > We'll see how OSGI works underload with Glassfish v3.
>> >
>>
>>  Are they planning to support "gapless" redeployment of web apps using
>> only
>> osgi features, with no other servlet container support?  If so is can you
>> point to an explanation of how they plan to do this?
> 
> There are many problems to solve for 'gapless' redeployment, but I
> think the biggest is
> sessions and statics. The classloader ( OSGI or not ) can keep
> multiple versions of
> the application loaded - but you need the mapper to know where to send
> each request.
> In theory it could be done even with the current tomcat, by including
> the version in the cookie and changing the mapper to use it.
> 
> But I think the main question is if it's worth it - there is a lot of
> complexity and many things that can go wrong. Very few advanced users
> will be able to use this - in particular if they have production
> environments and some release testing is required ( i.e. it would be
> quite hard to automate and test what will happen in gapless case). The
> alternative - having multiple machines/VMs running different versions
> behind a load balancer - is quite safe and I suspect the 'advanced
> users' who may need gapless would be better off using the old way.
> I mean - if you run your app out of a single VM, probably you won't
> need gapless, and if you already have load balancing/failover/multiple
> servers - you have a better/safer solution.
> 
> Costin
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Osgifing-Tomcat-tp16830131p16930343.html
Sent from the Tomcat - Dev mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message