In this article, a container locator support was introduced. Commonly known as aliases. At that time it was by default using latest available version of the project configured with same alias. This idea was really well received and thus further enhanced.
Pluggable container locator
First of all, not always latest available container is the way to go. There might be a need to have time bound container selection for given alias, for example:
- there are two containers for given alias
- even though there is a new version already deployed it should not be used until predefined date
so users might implement their own container locator interface and register it by including that implementation bundled into a jar file on KIE Server class path. As usual, the discovery mechanism is based on ServiceLoader so the jar must include:
- implementation of ContainerLocator interface
- file named org.kie.server.services.api.ContainerLocator must be placed in META-INF/services directory
- include fully qualified class name of the ContainerLocator implementation in META-INF/services/org.kie.server.services.api.ContainerLocator file
Since there might be multiple implementation present on class path, container locator to be used needs to be given via system property:
- org.kie.server.container.locator where the value should be class name of the implementation of ContainerLocator interface – simple name not FQCN
that will be then used instead of default latest container locator.
so far so good, but what should happen with containers that are now idle or should not be used anymore? Since the container locator will make sure that selected (by default latest) container is going to be used in most of the cases, there might be containers that do no need to be on runtime any longer. Especially important in environments where new versions of containers are frequently deployed which might lead to increased use of memory. Thus efficient cleanup of not used containers is a must.
Pluggable policy support
For this a policy support was added, but not only for this as policies are general purpose tool within KIE Server. So what’s that?
Policy is a set of rules that are applied by KIE Server periodically. Each policy can be registered at different time to be applied. Policies are discovered when KIE Server starts and are registered but are not started by default.
The reason for this is that the discovery mechanism (ServiceLoader) is based on class path scanning and thus are always performed regardless if they should be used or not. So there is another step required to make the policy to be activated.
Policy activation is done by system property when booking KIE Server:
- org.kie.server.policy.activate – where value is a comma separated list of policies (their names) to be activated
When policy manager activates given policy it will respect its life cycle:
- will invoke start method of the policy
- will retrieve interval from the policy (invoke getInterval method)
- schedule periodic execution of that policy based on given interval – if interval is less than 1 it will ignore that policy
NOTE: scheduling is done based on interval for both first execution and then repeatable executions – meaning first execution will take place after interval. Interval must be given in milliseconds.
Similar, when KIE Server stops it will call stop method of every activated policy to properly shut it down.
Policy support can be used for various use cases, one that comes out of the box is to complement container locator (with its default latest only). So there is a policy available in KIE Server that will undeploy other container than latest. This police by default is applied once a day, but can be reconfigured via system properties. KeepLatestContainerOnlyPolicy will attempt to dispose containers that have lower versions, though it might fail on such attempt. Reasons of the failure might vary but most common will be when there are active process instances for container that is being disposed. In that case the container is left as started and the next day (or after another reconfigured period of time) the attempt will be retried.
NOTE: KeepLatestContainerOnlyPolicy is aware of controller so it will notify controller that the policy was applied and stop container in controller only, but only stop it and not remove it. Same as any policy this one must be activated via system property as well.
This opens the door for tremendous amount of policy implementations, starting with cleanup, through blue-green deployments and finishing at reconfiguring runtimes. All performed periodically and automatically by KIE Server itself.
As always, comments and further ideas are more than welcome.