java - @Scheduled with cron 表达式突然停止工作

Question

我知道这个问题会重复出现，但我已经尝试了所有建议，但没有任何效果。 我正在使用 spring 1.4.3。 我使用的是 Elastic beanstalk，这样我的开发 EC2 实例类型:t2.small 与 EC2 实例类型:t2.large 的产品相比

直到今天我一直在尝试工作，突然它停止了，没有错误或任何东西......(这不仅是这项工作，也是我项目中的所有工作)

我的配置是:

  @Configuration
 @EnableAsync
 @EnableScheduling
  public class AppConfig{

  @Bean(destroyMethod = "shutdown")
public Executor taskScheduler() {
    return Executors.newScheduledThreadPool(5);
   }
} 

我正在尝试的工作非常简单:

 @Service
open class TestProcessing {
private val logger = LoggerFactory.getLogger(this.javaClass)
@Scheduled(fixedDelay = 5000)
fun startProcessing2(){
        logger.info("Test2 Job")
     }

 }

我的主要是:

  @SpringBootApplication(exclude = EndpointMBeanExportAutoConfiguration.class)
  public class ApiServerApplication {

public static void main(String[] args) {
    new SpringApplicationBuilder(ApiServerApplication.class).run(args);
   }
}

帖子请求:

     @ResponseBody
     @RequestMapping(
  path = arrayOf("", "/"),
  method = arrayOf(RequestMethod.POST),
  consumes = arrayOf(MediaType.APPLICATION_JSON_UTF8_VALUE))
    fun insertDispenserRecordsList(@RequestHeader(name = "xg-BAddress", required = false) reporter: String?,
                             @Valid @RequestBody dispenserRecords: DispenserRecordsList<DispenserRecordInput>,
                             bindingResult: BindingResult): ResponseEntity<*> {
        if (bindingResult.hasErrors()) {
        throw exception(bindingResult)
          }
        dispenserRecordsService.insertDispenserRecordsList(reporter, dispenserRecords.dispenserRecords)
       return ResponseEntity<Any>(HttpStatus.OK)

}

有趣的是，工作正在生产和本地工作，但不在开发上，它们之间的不同之处在于，在开发上每秒都有一个发布请求...... 它看起来像这样:

    2018-04-09 23:29:17.080  WARN 22763 --- [io-8080-exec-53] c.h.u.q.RequestStatisticsInterceptor     : [Time: 454 ms] [Queries: 3] POST /v1/dispensers/records
    2018-04-09 23:29:17.316  WARN 22763 --- [io-8080-exec-49] c.h.u.q.RequestStatisticsInterceptor     : [Time: 213 ms] [Queries: 3] POST /v1/wristbands/records
    2018-04-09 23:29:20.396  WARN 22763 --- [nio-8080-exec-3] c.h.u.q.RequestStatisticsInterceptor     : [Time: 180 ms] [Queries: 3] POST /v1/wristbands/records
    2018-04-09 23:29:21.115  WARN 22763 --- [io-8080-exec-30] c.h.u.q.RequestStatisticsInterceptor     : [Time: 206 ms] [Queries: 3] POST /v1/wristbands/records
    2018-04-09 23:29:21.284  WARN 22763 --- [io-8080-exec-33] c.h.u.q.RequestStatisticsInterceptor     : [Time: 215 ms] [Queries: 3] POST /v1/wristbands/records
    2018-04-09 23:29:21.927  WARN 22763 --- [io-8080-exec-61] c.h.u.q.RequestStatisticsInterceptor     : [Time: 251 ms] [Queries: 3] POST /v1/wristbands/records
    2018-04-09 23:29:22.667  WARN 22763 --- [nio-8080-exec-9] c.h.u.q.RequestStatisticsInterceptor     : [Time: 159 ms] [Queries: 3] POST /v1/wristbands/records
    2018-04-09 23:29:25.203  WARN 22763 --- [io-8080-exec-44] c.h.u.q.RequestStatisticsInterceptor     : [Time: 265 ms] [Queries: 3] POST /v1/wristbands/records
    2018-04-09 23:29:27.754  WARN 22763 --- [io-8080-exec-28] c.h.u.q.RequestStatisticsInterceptor     : [Time: 213 ms] [Queries: 4] POST /v1/wristbands/records
    2018-04-09 23:29:28.160  WARN 22763 --- [io-8080-exec-64] c.h.u.q.RequestStatisticsInterceptor     : [Time: 219 ms] [Queries: 3] POST /v1/wristbands/records
    2018-04-09 23:29:31.733  WARN 22763 --- [io-8080-exec-13] c.h.u.q.RequestStatisticsInterceptor     : [Time: 189 ms] [Queries: 3] POST /v1/wristbands/records
    2018-04-09 23:29:32.212  WARN 22763 --- [io-8080-exec-37] c.h.u.q.RequestStatisticsInterceptor     : [Time: 363 ms] [Queries: 3] POST /v1/wristbands/records
    2018-04-09 23:29:35.390  WARN 22763 --- [io-8080-exec-12] c.h.u.q.RequestStatisticsInterceptor     : [Time: 374 ms] [Queries: 3] POST /v1/wristbands/records
    2018-04-09 23:29:36.167  WARN 22763 --- [io-8080-exec-59] c.h.u.q.RequestStatisticsInterceptor     : [Time: 174 ms] [Queries: 3] POST /v1/wristbands/records
    2018-04-09 23:29:37.918  WARN 22763 --- [io-8080-exec-34] c.h.u.q.RequestStatisticsInterceptor     : [Time: 188 ms] [Queries: 3] POST /v1/wristbands/records
    2018-04-09 23:29:41.144  WARN 22763 --- [io-8080-exec-24] c.h.u.q.RequestStatisticsInterceptor     : [Time: 199 ms] [Queries: 3] POST /v1/wristbands/records
    2018-04-09 23:29:43.337  WARN 22763 --- [io-8080-exec-34] c.h.u.q.RequestStatisticsInterceptor     : [Time: 192 ms] [Queries: 3] POST /v1/wristbands/records
    2018-04-09 23:29:44.361  WARN 22763 --- [io-8080-exec-48] c.h.u.q.RequestStatisticsInterceptor     : [Time: 176 ms] [Queries: 3] POST /v1/wristbands/records
    2018-04-09 23:29:45.624  WARN 22763 --- [nio-8080-exec-7] c.h.u.q.RequestStatisticsInterceptor     : [Time: 352 ms] [Queries: 3] POST /v1/wristbands/records
    2018-04-09 23:29:46.094  WARN 22763 --- [io-8080-exec-37] c.h.u.q.RequestStatisticsInterceptor     : [Time: 186 ms] [Queries: 3] POST /v1/wristbands/records

如果您需要更多详细信息，请告诉我... 谢谢您的帮助

Answer 1

情况表明，这是因为在开发中，每个 POST 请求都在执行某些任务或调用等待其响应的任何其他外部系统。 一种可能的解决方案是定义 POST 请求的超时，该超时应小于 @Sceduled 时间。 对于从数据库获取记录列表的 POST 请求，我遇到了同样的问题。

@RequestMapping(method = RequestMethod.POST)
ResponseEntity<?> add(@PathVariable String userId, @RequestBody Bookmark input) {
    this.validateUser(userId);

    return this.accountRepository
            .findByUsername(userId)
            .map(account -> {
                Bookmark result = bookmarkRepository.save(new Bookmark(account,
                        input.getUri(), input.getDescription()));

                URI location = ServletUriComponentsBuilder
                    .fromCurrentRequest().path("/{id}")
                    .buildAndExpand(result.getId()).toUri();

                return ResponseEntity.created(location).build();
            })
            .orElse(ResponseEntity.noContent().build());

}

这等待服务的响应。在您的情况下，POST 请求必须异步等待响应，否则它不能在 Prod 或 Local 中运行。