How hot deployment works internally?

会有一股神秘感。 提交于 2019-12-01 04:17:05
Anton Arhipov

Hot code deployment depends on the runtime capabilities. The answer you linked to does not mean that the automation stops the server deploys the new code and starts the server again. This would have been wasteful.

Instead, most of the Java application servers are able to redeploy the application. It means that the server would create a new web application class loader, load the new version of the application by this new class loader, in some cases it will migrate state (serialize/deserialize HTTP session), and drop the old version of the application.

Now the redeploy speed depends very much on the application itself -- how the application is initialized. Does it have to warmup caches? Does it have to satisfy the dependencies (a-las Spring, CDI)? Does it have to initialize Hibernate SessionFactory? Many factors are involved.

What Eclipse WTP naturally does is that it can trigger the redeployment process for the application container - that's it. A small application will not take long to redeploy, of course.

Unless there's a special runtime technology/container/framework and there is a special connector developed for Eclipse to take advantage of a hook that would trigger hot code updated for that specific technology. A good example is bndtools for OSGi runtime.

And just to remove some confusion:

Often people confuse HotSwap and hot deployment. The first one, HotSwap, is the ability of JVM to update class definition at runtime. The latter one, hot deployment, is the ability of application server to automatically deploy application, either incrementally or not, without restarting the JVM process.

So my answer is about hot deployment, and not about HotSwap. Hence I refer to hot deployment as an "automation" rather than a fundamental mechanism of the platform.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!