@Scheduled for non-Singleton Beans: currently @Scheduled creates separate bean instances instead scheduling existing

[patrickmhaller]

Feature description

The intention is to have methods annotated with @Scheduled on non-Singleton beans, and to get the methods called by the scheduler for only bean instances that got created due to other bean instantiations.

I could not find documentation describing the observed behavior or how @Scheduled is specified to work in this particular scenario with non-Singleton beans.

Exemplary Use Case

• Intention was to have a scheduled watchdog method on a streaming WebSocket that verifies the delay since the last message was received on the WebSocket. If no message was received in time, reconnect the socket.
• the watchdog-method annotated with @Scheduled, however, led to an implicit instantiation of a separate bean instance. The WebSocket connection was managed by a non-Singleton bean.

Problem

• the called back watchdog-method then operates on a non-initialized / non-connected "orphan" instance of the WebSocket connection bean.
• the actual connected WebSocket connection bean instance did not get any scheduler callbacks.

Idea

1. For non-Singleton beans, the @Scheduled annotations get only evaluated when the bean is instantiated. Then all found annotated methods get registered with the Micronaut Scheduler along with their parent bean instance, such that the callbacks operate on the existing bean instance(s).
2. The registered callback methods get automatically deregistered when the bean instance terminates.
3. The registration of callback methods with the Micronaut Scheduler does not hold strong references, so the parent bean instance can terminate and get GC'ed at any time.

Workaround

Classic registration of lambas / Runnables as TimerTasks with java.util.Timer is a viable alternative.