taskScheduler池的奇怪行为

Question

我有两个spring引导应用程序(1.4.3.RELEASE)，它们位于同一台服务器上。app A是一个单块应用程序，包含用于处理警报的部分代码，而app B是一个新的专用应用程序，只处理警报。这里的目标是打破小应用程序中的单色应用程序。现在，这两种代码一起运行，因为我有一些老系统，它们总是调用应用程序A。

这两个应用程序都配置了一个基于taskScheduler的ThreadPoolTaskScheduler。

@Configuration
public class TaskSchedulerConfig {

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

        return threadPoolTaskScheduler;
    }
}

昨天，我经历了一种奇怪的行为：

1. 已检测到警报并发送到新的应用程序B -> OK
2. 应用程序B接收到警报，并开始根据taskScheduler -> OK进行处理。
3. 第一步已由app B -> OK处理。
4. 第二步已由应用程序A -> NOK处理，奇怪的行为
5. 第三步已由app按预期的->确定处理。

这怎么可能？对我来说，每个taskScheduler都附加到创建它的应用程序上。我哪里错了？

更新

我有一个真正的盒子能发出警报。这些警报必须由新应用程序处理。但我也有旧的盒子，没有迁移到新的系统。所以我有两个不同的项目的处理代码。

我有一个带有新代码的新框，它在新系统上创建了一个警报。此警报生成状态机，该状态机以异步方式与任务调度程序一起处理。在创建警报之后，新应用程序开始处理状态机，在处理过程的中间，旧应用程序唤醒并处理警报的一步。之后，新应用程序再次唤醒并正常关闭警报。

问题是:为什么老应用程序醒来处理警报？threadPoolTaskScheduler是否存在已知的问题？

Answer 1

两个不同的应用程序不可能有这种行为，因为它们在独立的进程中运行。线程(同一进程)在共享内存空间中运行，而进程在单独的内存空间中运行，因此它们之间没有“桥”。

如果他们共享相同的数据库，他们可能会监听相同的事件，但前提是您实现了这个逻辑。

如果我不得不猜测，考虑到这两者都是had应用程序，我会说代码中可能有一些HTTP调用，目标仍然是一个旧的端点，或者其他一些触发器(crons?)在启动旧应用程序的服务器内部。