-
Notifications
You must be signed in to change notification settings - Fork 705
Index
JarsLink creates a new URLClassLoader for each module for loading JAR. It also supports breaking through the parental delegation mechanism setting that the overridePackages are loaded by subclass loaders and not taking priority to use packages that have been loaded by the parent class loader.
Unloading a module can only occur when certain conditions are met. Specifically, the instance object, classes, and class loaders cannot be referenced in the module. Therefore, the instances, classes, and class loaders need to be unloaded. The sequence of unloading the entire module is shown below.
(JarsLink module unloading sequence)
Different functions are performed at each step of the sequence:
- Close resources Close the HTTP connection pool or thread pool.
- Close IOC Containers Call the applicationContext.close() method to close IOC Containers.
- Remove class loaders Remove the reference of the module.
- Unload JVM Tenants (in development) Unload the JVM tenants used by this module to free up resources.
To prevent modules influencing each other, a key attribute of modular development is module isolation. There are three levels of isolation between modules:
- Class isolation Create a class loader for each module to implement class isolation.
- Instance isolation Create a new IOC container for each module to load the bean in the module.
- Resource isolation Only use the specified CPU and memory for each module.
The relationships between these are illustrated below.
(Module isolation in the JarsLink framework)
Currently, class isolation and instance isolation have been realized for JarsLink. Resource isolation is still in the planning stage and will potentially be solved by introducing ALIJVM multi-tenancy.
The main methods to facilitate communications between modules include:
- Local calls
This required that the module class loaders and IOC containers have a parent-child relationship. Currently, JarsLink's doAction uses this communication method.
- RPC calls
This is used for cross-JVM module calls using SOFA 4 dynamic APIs to publish and reference TR services in the modules.
- Deep cloning/reflection
Deeply clone and reflect the input parameters of other modules to achieve the call.
An illustration of these communications is outlined below.