java - taskScheduler 池的奇怪行为

Question

我在同一台服务器上有两个 spring boot 应用程序 (1.4.3.RELEASE)。应用程序 A 是一个单体应用程序，其中包含用于处理警报的部分代码，而应用程序 B 是一个仅处理警报的新专用应用程序。这里的目标是打破小应用程序中的单一应用程序。现在，这两个代码一起运行，因为我的旧系统总是调用应用程序 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. app B收到alert，开始根据taskScheduler处理 -> OK
3. 第一步已被应用B处理 -> OK
4. 应用程序 A 已处理第二步 -> NOK，奇怪的行为
5. 应用程序 B 已按预期处理了第三步 -> OK

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

更新

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

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

问题是:为什么旧应用程序会唤醒以处理警报？ threadPoolTask​​Scheduler 是否存在已知问题？

Answer 1

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

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

如果我不得不猜测，鉴于两者都是网络应用程序，我会说代码中某处可能有一些 HTTP 调用，仍然针对旧端点，或者服务器内部的一些其他触发器(crons？)启动旧应用。