Shutdown-Mechanism of DbSchedulerDeadlineManager about axonframework HOT 12 CLOSED

It might also have to do with multiple instances. And possible also calls from either Spring Boot, or the scheduler auto configuration itself. Together with this , it would be easy to use the concurrent hashmap to always only have one 'real' shutdown.

from axonframework.

Hi @gklijs,

The issue is also observable when using only a single instance of the DbSchedulerDeadlineManager. The reason is probably that multiple shutdown handlers are registered.

The first shutdown method is registered by dbscheduler itself, as the DbSchedulerAutoConfiguration has a bean definition of the Scheduler with stop as destroy method. So far, dbscheduler is the only one handling the start and the stop methods.

Now we have additional handlers registered by the AxonDbSchedulerAutoConfiguration in the form of the DbSchedulerEventScheduler and the DbSchedulerDeadlineManager. Due to the calls in registerLifecycleHandlers both the start and the stop methods of the Scheduler are called again - twice. About the remaining calls, I am not so sure, but both components in question are also implementing the Lifecycle interface, so maybe this is the reason.

In any case: As far as I can see, the auto configuration of dbscheduler seems to handle everything regaring starting and stopping the Schedule already, so I don't think the Axon components are responsible for doing this as well.

Best regards

Nils

from axonframework.

Well, unless you don't use the auto configuration of DbScheduler. So maybe the shop behavior should be configurable, just like the auto start already is?

from axonframework.

Hi @gklijs,

I am not sure. The AxonDbSchedulerAutoConfiguration is only active if there is a Scheduler bean in the context. This indicates that whoever creates said bean (be it manually with a custom configuration or simply by using the DbSchedulerAutoConfiguration) is also responsible for the lifecycle of the bean. So I don't think the Axon components should be responsible for handling it.

If, on the other hand, we say that the AxonDbSchedulerAutoConfiguration is (maybe optionally by setting a flag) responsible for handling the lifecycle of the Scheduler, it should - in my opinion - still handle it differently:

• Instead of starting/stopping the scheduler twice within two different components, a dedicated component should be responsible for doing so once.
• The auto configuration of Axon would need to provide a custom DbSchedulerStarter bean to disable the default behaviour of dbscheduler:

private static final class NeverStartingDbSchedulerStarter implements DbSchedulerStarter {

  @Override
  public void doStart( ) {
    // Should never be called
  }

}

• To fully control the shutdown of the Scheduler, Axon would also need to provide a custom Scheduler bean definition without registering stop as destroy method. This is getting more complicated, as the corresponding auto configuration cannot be active if there is a Scheduler bean - because now it is responsible for creating said bean.

In summary I think it would be more feasable to delegate the lifecycle handling of the Scheduler to dbscheduler or to whoever creates the Scheduler bean.

Best regards

Nils

from axonframework.

In addition to that, I asked the dbscheduler developers for a better possibility to control the shutdown: kagkarlsson/db-scheduler#423

from axonframework.

We already disabled the auto start. The problem is that we don't know on the DbSchedulerDeadlineManager where the Scheduler came from. We can offer some configuration, and we need some defaults.

As we also start the scheduler by default now, would you ideally remove that? And make it clear from the Javadoc on the DbSchedulerDeadlineManager that it's not the responsibility to control the lifetime of the Scheduler?

Since they are closely related, that does not really click with me. But neither does it to have the startup configurable, but not the shutdown.

from axonframework.

Well, Axon is relying on an "external" bean, so I think it would be reasonable to argue that Axon does not have to control the lifecycle. Especially because the default auto configurations will already start and stop everything as expected.

I suggest to wait for kagkarlsson/db-scheduler#423. If dbscheduler provides means to control the shutdown behaviour, Axon could probably take full control of the lifecycle.

from axonframework.

Indeed, the 'problem' is mainly how best to accommodate non-Spring users. But since that is such a wide range, that is hard.

from axonframework.

Added the status "information required" as we're waiting for a reply on kagkarlsson/db-scheduler#423.
@nils-christian, would you be able to share with us the response once it comes in? I assume you're already watching said issue, as you've created it :-)

from axonframework.

Sounds good to me, @smcvb.

from axonframework.

Removing "in progress" status label and unassigning @gklijs, as PR #2852 has been approved and merged.

from axonframework.

Closing the issue as the predicament has been resolved.
However, the status label "information required" remains, as I would still be curious about the info shared by the db-scheduler team.

from axonframework.