[KF] What is the scope of FeatureEntryPoint.stop()?

MicroEJ SDK
1

Hello,

I’ve been looking into application management with KF.
After reading section 5.5 of KF specification (Feature Lifecycle: Stop), it is unclear to me how the following statement applies for the “stop thread” (the one executing FeatureEntryPoint.stop()):

Marks all objects owned by the Feature as dead objects, which implies that a
ej.kf.DeadFeatureException is thrown in threads that are running the stopped Feature
code or in threads that want to call stopped Feature code, or threads that accesses to objects
owned by the stopped Feature.

As a side question: what is the scope of what the FeatureEntryPoint.stop() can/should/is expected to do ?

Thanks,
Alan

2

Hi Alan,

The Java stop() method is the last executed hook to give a chance to the Feature to perform close actions properly. A new thread owned by the Feature is created to call the stop() method:

image

After the timeout occurs, the underlying Feature is stopped, and if this thread is not normally terminated, it will be killed as well as other active threads owned by the Feature.

–Frédéric

3

Hi Frédéric,

Thank you for the clarification:
Now, I understand that this thread is actually executed before the application is “killed” (as descripted by the previously quoted statement).

I was wrongly assuming that the following task was a recommendation for the Kernel developer:

Wait until this new
thread is done, and timeout of a global timeout stop-time occurred¹.

¹A decent global timeout stop-time is 2,000ms.

But it is actually implemented by KF, I confirmed that by looking into KF sources.
In the kf-1.5.jar I have, in ej/kf/Kernel.java:

	/**
	 * Timeout for the call of {@link FeatureEntryPoint#stop()}.<br>
	 * TODO: Must be configurable.
	 */
	/*default*/ static final long STOP_TIMEOUT = 2000;;

Do you have a plan for this to be configurable ?

Reading the sources also clarifies another point: the FeatureEntryPoint.stop() is only called at the first Feature.stop() call. So FeatureEntryPoint.stop() will never be called after the application is “killed” (in STOPPED / INSTALLED states).

Regards,
Alan

4

You are right, the timeout should be configurable using an option.
I created an internal issue for this.

Thanks for the feedback.
–Frédéric