taskScheduler池的奇怪行為

Question

我有兩個彈簧啟動應用程序（1.4.3.RELEASE），它們位於同一台服務器上。 應用程序A是一個單一的應用程序，其中包含用於處理警報的部分代碼，而應用程序B是一個僅處理警報的新專用應用程序。 這里的目標是打破小應用程序中的monolotic應用程序。 現在，這兩個代碼一起運行，因為我有舊系統，總是調用應用程序A.

這兩個應用程序有一個基於ThreadPoolTask​​Scheduler配置的taskScheduler。

@Configuration
public class TaskSchedulerConfig {

    @Bean
    public TaskScheduler taskScheduler() {
        ThreadPoolTaskScheduler threadPoolTaskScheduler = new ThreadPoolTaskScheduler();
        threadPoolTaskScheduler.setWaitForTasksToCompleteOnShutdown(true);
        threadPoolTaskScheduler.setPoolSize(100);

        return threadPoolTaskScheduler;
    }
}

昨天，我經歷了一個奇怪的行為：

1. 檢測到警報並將其發送到新應用程序B - >確定
2. 應用程序B收到警報並開始根據taskScheduler處理它 - >確定
3. 第一步已由應用程序B處理 - >確定
4. 第二步已經被app A - > NOK處理，這是一種奇怪的行為
5. 第三步已由應用程序B按預期處理 - >確定

這怎么可能？ 對我來說，每個taskScheduler都附加到創建它的應用程序。 我哪里錯了？

UPDATE

我有一個發出警報的真實盒子。 這些警報必須由新應用程序處理。 但我還有舊盒子沒有遷移到新系統。 所以我在兩個不同的項目中有處理代碼。

我有一個新代碼的新框，它在新系統上創建了一個警報。 此警報生成一個狀態機，該狀態機與任務調度程序異步處理。 創建警報后，新應用程序開始處理狀態機，並在處理過程中喚醒舊應用程序並處理警報步驟。 之后，新應用程序再次喚醒並正常關閉警報。

問題是：為什么舊應用程序會喚醒以處理警報？ threadPoolTask​​Scheduler是否存在已知問題？

Answer 1

由於它們在隔離的進程中運行，因此兩種不同的應用程序無法實現此行為。 線程（相同進程）在共享內存空間中運行，而進程在不同的內存空間中運行，因此它們之間沒有“橋接”。

如果它們共享同一個數據庫，則它們可能正在偵聽相同的事件，但前提是您已實現該邏輯。

如果我不得不猜測，鑒於兩者都是webapps，我會說在代碼中的某個地方可能會有一些HTTP調用，仍然針對一個舊的端點，或者服務器內的一些其他觸發器（crons？）啟動舊的應用程序。