Update application shutdown logic #1760

Yavor16 · 2026-01-05T09:21:11Z

No description provided.

...loudfoundry/multiapps/controller/core/application/shutdown/ApplicationShutdownScheduler.java

...iapps-controller-core/src/main/java/org/cloudfoundry/multiapps/controller/core/Messages.java

...loudfoundry/multiapps/controller/core/application/shutdown/ApplicationShutdownScheduler.java

...src/main/java/org/cloudfoundry/multiapps/controller/persistence/dto/ApplicationShutdown.java

.../main/java/org/cloudfoundry/multiapps/controller/persistence/dto/ApplicationShutdownDto.java

...t/src/main/java/org/cloudfoundry/multiapps/controller/shutdown/client/util/ShutdownUtil.java

theghost5800 · 2026-01-07T09:01:58Z

.../java/org/cloudfoundry/multiapps/controller/shutdown/client/ApplicationShutdownExecutor.java

-            instanceShutdownExecutor.execute(applicationGuid, i);
+    public void execute(String applicationId, int applicationInstanceCount) {
+        ApplicationShutdownScheduler applicationShutdownScheduler = getApplicationShutdownScheduler();
+        List<ApplicationShutdown> scheduledApplicationShutdowns = applicationShutdownScheduler.scheduleApplicationForShutdown(applicationId,


What will happen if count of instances is mistaken or some of existing instances are in crashed/not running state? Will it lead to infinite loop?

i dont it will because if an instance has crashed on startup, the instance will delete the scheduled entry from the database so there won't be attempts for shutdown.
also if we scheduled 5 instances for shutdown but in reality there are 3, we will shutdown the intances from 1-3. the entries for shutdown for instance 4 and 5 won't be cleared from the database. when we increase the instances back to 5, the scheduled entries will be cleared from the database.
If we schedule 3 instances but there are 5, only the first 3 will be shutdown. the other 2 won't be shutdown

Maybe we have to think to add some cleanup of such data from db because there is a case if we scale up instances and run for some time in this way and after several shutdown of instances, we decide to reduce app instances, it will schedule to shutdown for example 5 instances but after shutdown, startup of new application will be with 3 instances for example and data in db for 4 and 5 instance won't be deleted and if we decide again to increase instances, it will potentially start and try to shutdown instances 4 and 5 immediately.
Is there any guarantee that scheduler thread for monitoring for shutdown action does not run before bootstrapservlet where data for shutdown action will be deleted?

...in/java/org/cloudfoundry/multiapps/controller/web/resources/ApplicationShutdownResource.java

pom.xml

...-web/src/main/java/org/cloudfoundry/multiapps/controller/web/bootstrap/BootstrapServlet.java

...loudfoundry/multiapps/controller/core/application/shutdown/ApplicationShutdownScheduler.java

...a/org/cloudfoundry/multiapps/controller/persistence/services/ApplicationShutdownService.java

.../main/java/org/cloudfoundry/multiapps/controller/persistence/dto/ApplicationShutdownDto.java

...g/cloudfoundry/multiapps/controller/persistence/query/impl/ApplicationShutdownQueryImpl.java

...src/main/java/org/cloudfoundry/multiapps/controller/process/jobs/ApplicationShutdownJob.java

stiv03 · 2026-01-08T09:24:23Z

...src/main/java/org/cloudfoundry/multiapps/controller/process/jobs/ApplicationShutdownJob.java

+    private void shutdownApplication(ApplicationShutdown applicationShutdown) {
+        CompletableFuture.runAsync(() -> {
+                             logProgressOfShuttingDown(applicationShutdown, Messages.SHUTTING_DOWN_APPLICATION_WITH_ID_AND_INDEX);
+                             flowableFacade.shutdownJobExecutor();
+                         })
+                         .thenRun(() -> logProgressOfShuttingDown(applicationShutdown, Messages.SHUT_DOWN_APPLICATION_WITH_ID_AND_INDEX));
+    }


Is it possible here, exception to be thrown inside the async task, this will impact the DB state in a wrong way. Maybe add FAILED status for such cases.

stiv03 · 2026-01-08T09:50:33Z

Also add some unit tests, cause now there is 0.0% Coverage on New Code

...src/main/java/org/cloudfoundry/multiapps/controller/process/jobs/ApplicationShutdownJob.java

theghost5800 · 2026-01-27T15:44:20Z

.../java/org/cloudfoundry/multiapps/controller/shutdown/client/ApplicationShutdownExecutor.java

-            instanceShutdownExecutor.execute(applicationGuid, i);
+    public void execute(String applicationId, int applicationInstanceCount) {
+        ApplicationShutdownScheduler applicationShutdownScheduler = getApplicationShutdownScheduler();
+        List<ApplicationShutdown> scheduledApplicationShutdowns = applicationShutdownScheduler.scheduleApplicationForShutdown(applicationId,


Maybe we have to think to add some cleanup of such data from db because there is a case if we scale up instances and run for some time in this way and after several shutdown of instances, we decide to reduce app instances, it will schedule to shutdown for example 5 instances but after shutdown, startup of new application will be with 3 instances for example and data in db for 4 and 5 instance won't be deleted and if we decide again to increase instances, it will potentially start and try to shutdown instances 4 and 5 immediately.
Is there any guarantee that scheduler thread for monitoring for shutdown action does not run before bootstrapservlet where data for shutdown action will be deleted?

...g/cloudfoundry/multiapps/controller/persistence/services/ApplicationShutdownServiceTest.java

LMCROSSITXSADEPLOY-3344 # Conflicts: # multiapps-controller-process/src/main/java/org/cloudfoundry/multiapps/controller/process/Messages.java # Conflicts: # multiapps-controller-core/src/main/java/org/cloudfoundry/multiapps/controller/core/Messages.java # multiapps-controller-web/src/main/java/org/cloudfoundry/multiapps/controller/web/resources/ApplicationShutdownResource.java # Conflicts: # multiapps-controller-core/src/main/java/org/cloudfoundry/multiapps/controller/core/Messages.java # multiapps-controller-web/src/main/java/org/cloudfoundry/multiapps/controller/web/resources/ApplicationShutdownResource.java # Conflicts: # multiapps-controller-core/src/main/java/org/cloudfoundry/multiapps/controller/core/Messages.java # multiapps-controller-web/src/main/java/org/cloudfoundry/multiapps/controller/web/resources/ApplicationShutdownResource.java

theghost5800 · 2026-01-28T13:24:23Z

...a/org/cloudfoundry/multiapps/controller/process/jobs/LeftoverApplicationShutdownCleaner.java

+    private void deleteLeftoverApplicationShutdowns(List<ApplicationShutdown> leftoverApplicationShutdowns) {
+        leftoverApplicationShutdowns.forEach(applicationShutdown -> applicationShutdownService.createQuery()
+                                                                                              .id(applicationShutdown.getId())
+                                                                                              .delete());


Make it to be deleted all entries with single query instead of new db query for every entry.
Another approach for this is calculate older than timestamp in java code and execute db query with timestamp condition, in this way it will avoid processing in java code.

stiv03 · 2026-01-28T13:16:01Z

...a/org/cloudfoundry/multiapps/controller/process/jobs/LeftoverApplicationShutdownCleaner.java

+        deleteLeftoverApplicationShutdowns(leftoverApplicationShutdowns);
+        LOGGER.info(MessageFormat.format(Messages.DELETED_LEFTOVER_APPLICATION_SHUTDOWNS, leftoverApplicationShutdowns.size()));


Maybe we can also add a log for which shutdown is deleted

With the new implementation this is not possible anymore

stiv03 · 2026-01-28T13:20:30Z

...t/src/main/java/org/cloudfoundry/multiapps/controller/shutdown/client/util/ShutdownUtil.java

+        return isTimeExceeded(applicationShutdown, DAY_IN_SECONDS);
+    }
+
+    private static boolean isTimeExceeded(ApplicationShutdown applicationShutdown, int seconds) {


Maybe use Duration type here instead of int

This method is changed now

stiv03 · 2026-01-28T13:23:28Z

...t/src/main/java/org/cloudfoundry/multiapps/controller/shutdown/client/util/ShutdownUtil.java

+        Instant secondsAfterStartedDate = Instant.from(applicationShutdown.getStartedAt()
+                                                                          .toInstant())
+                                                 .plusSeconds(seconds);
+        Instant timeNow = Instant.now();
+        return timeNow.isAfter(secondsAfterStartedDate);


is this double conversion .toInstant() necessary, also can .getStartedAt()be null and throw NPE?

I don't think it is possible because when we create a new ApplicationShutdown we set the time every time

stiv03 · 2026-01-28T13:27:32Z

...g/cloudfoundry/multiapps/controller/process/jobs/LeftoverApplicationShutdownCleanerTest.java

+
+    @Test
+    void testExecuteWithLeftoverApplications() {
+        Date timeBeforeTwoDays = new Date(1738061834);


I dont thinks this is 2 days ago :D

It is a little more than two days :D. The test doesn't exist anymore

stiv03 · 2026-01-28T13:31:24Z

...g/cloudfoundry/multiapps/controller/process/jobs/LeftoverApplicationShutdownCleanerTest.java

+
+        verify(applicationShutdownService, times(2)).createQuery();
+        verify(applicationShutdownQuery).list();
+        verify(applicationShutdownQuery).delete();


Maybe we can also check for a specific applicationShutdown id to be sure that we r deleting the right one

Removed this test

theghost5800 · 2026-01-29T07:20:53Z

...src/main/java/org/cloudfoundry/multiapps/controller/persistence/dto/ApplicationShutdown.java

+package org.cloudfoundry.multiapps.controller.persistence.dto;

-import org.immutables.value.Value;
+import java.util.Date;


One last thing, can you replace usage of java.util.Date with java.time.LocalDateTime all object related to shutdown because this api is quite old and have different issues - https://programminghints.com/2017/05/still-using-java-util-date-dont/

I have checked that all other query classes is using LocalDateTime or ZonedDateTime for timestamp objects.

sonarqubecloud · 2026-01-29T11:06:15Z

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
82.6% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

Yavor16 force-pushed the application-shutdown-logic-update branch 2 times, most recently from 31b61f2 to 8da103c Compare January 5, 2026 09:25

theghost5800 reviewed Jan 7, 2026

View reviewed changes

stiv03 suggested changes Jan 8, 2026

View reviewed changes

Yavor16 force-pushed the application-shutdown-logic-update branch 4 times, most recently from 1879759 to 22db5eb Compare January 13, 2026 12:55

Yavor16 force-pushed the application-shutdown-logic-update branch from 22db5eb to 92c2584 Compare January 23, 2026 06:33

theghost5800 reviewed Jan 27, 2026

View reviewed changes

Yavor16 added 2 commits January 28, 2026 11:29

fix comments

e3a0042

Yavor16 force-pushed the application-shutdown-logic-update branch 2 times, most recently from c9e7df2 to e55774f Compare January 28, 2026 11:00

Fix comments

492d215

Yavor16 force-pushed the application-shutdown-logic-update branch from e55774f to 492d215 Compare January 28, 2026 11:07

theghost5800 reviewed Jan 28, 2026

View reviewed changes

stiv03 suggested changes Jan 28, 2026

View reviewed changes

Fix comments

52c689d

Yavor16 force-pushed the application-shutdown-logic-update branch from 89e5530 to 52c689d Compare January 29, 2026 06:16

theghost5800 reviewed Jan 29, 2026

View reviewed changes

theghost5800 previously approved these changes Jan 29, 2026

View reviewed changes

Yavor16 dismissed theghost5800’s stale review via 62d9735 January 29, 2026 08:56

Yavor16 force-pushed the application-shutdown-logic-update branch from d0fe23b to 62d9735 Compare January 29, 2026 08:56

stiv03 approved these changes Jan 29, 2026

View reviewed changes

Yavor16 force-pushed the application-shutdown-logic-update branch 2 times, most recently from a040377 to 76f45db Compare January 29, 2026 10:54

fix comments

a2cdbf5

Yavor16 force-pushed the application-shutdown-logic-update branch from 76f45db to a2cdbf5 Compare January 29, 2026 11:00

theghost5800 approved these changes Jan 29, 2026

View reviewed changes

stiv03 approved these changes Jan 29, 2026

View reviewed changes

Yavor16 merged commit 8445795 into master Jan 29, 2026
8 checks passed

Yavor16 deleted the application-shutdown-logic-update branch January 29, 2026 12:40

		deleteLeftoverApplicationShutdowns(leftoverApplicationShutdowns);
		LOGGER.info(MessageFormat.format(Messages.DELETED_LEFTOVER_APPLICATION_SHUTDOWNS, leftoverApplicationShutdowns.size()));

Update application shutdown logic #1760

Update application shutdown logic #1760

Uh oh!

Conversation

Yavor16 commented Jan 5, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stiv03 commented Jan 8, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Yavor16 Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sonarqubecloud bot commented Jan 29, 2026

Quality Gate passed

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Yavor16 Jan 29, 2026 •

edited

Loading