Apache HTTPClient5-如何防止连接/流被拒绝

Question

• 我是一名软件工程师，负责测试餐厅菜单项的订单排列，以确认它们通过POS成功下单
  • 简而言之，这会将一个JSON负载发布到一个endpoint，该endpoint然后验证带有POS的顺序，以定义成功/失败/其他
  • 其中POS和每秒交易量（TPS）可能不同，但每个后端使用相同的核心处理
  • 这可能高达每项22000个排列，JSON大小易于管理，需要尽快处理
  • 根据正在测试的餐厅和/或地区的不同，网络可能会有很大的差异
    • E、 g.其中一些延迟比其他延迟高得多
    • 我正在使用Apache的HTTP客户端5 w/poolgasyncclientconnectionmanager来执行菜单内容的GET和检查订单是否成功的POST

    if (connState == ConnectionHandshake.GRACEFUL_SHUTDOWN) {
        throw new H2StreamResetException(H2Error.PROTOCOL_ERROR, "Stream refused");
    }
    

    • 尝试使用搜索引擎查找答案，但HTTPClient5的点击次数很少
    • 尝试使用官方留档但这很稀疏
    • 将每个路由的最大连接更改为减少的数量，移动不活动验证或连接存活时间
      • 其中不活动检查可能会修复POST，但会为某些事务暂停GET
      • 一个区域/餐厅的调整可能适用于1个区域/餐厅，然后适用于另一个区域/餐厅，仅将网络作为变量

      PoolingAsyncClientConnectionManagerBuilder builder = PoolingAsyncClientConnectionManagerBuilder
              .create()
              .setTlsStrategy(getTlsStrategy())
              .setMaxConnPerRoute(12)
              .setMaxConnTotal(12)
              .setValidateAfterInactivity(TimeValue.ofMilliseconds(1000))
              .setConnectionTimeToLive(TimeValue.ofMinutes(2))
              .build();
      

      • 转换到自定义Request配置不同的超时

      java prettyprint-override">private HttpClientContext getHttpClientContext() {
          RequestConfig requestConfig = RequestConfig.custom()
                  .setConnectTimeout(Timeout.of(10, TimeUnit.SECONDS))
                  .setResponseTimeout(Timeout.of(10, TimeUnit.SECONDS))
                  .build();
      
          HttpClientContext httpContext = HttpClientContext.create();
          httpContext.setRequestConfig(requestConfig);
          return httpContext;
      }
      

      （除上述部分外，还有变更尝试）

      • 对init和get响应的包装处理

      public SimpleHttpResponse getFullResponse(String url, PoolingAsyncClientConnectionManager manager, SimpleHttpRequest req) {
                  try (CloseableHttpAsyncClient httpclient = getHTTPClientInstance(manager)) {
                      httpclient.start();
      
                      CountDownLatch latch = new CountDownLatch(1);
                      long startTime = System.currentTimeMillis();
                      Future<SimpleHttpResponse> future = getHTTPResponse(url, httpclient, latch, startTime, req);
      
                      latch.await();
                      return future.get();
                  } catch (IOException | InterruptedException | ExecutionException e) {
                      e.printStackTrace();
                      return new SimpleHttpResponse(999, CommonUtils.getExceptionAsMap(e).toString());
                  }
              }
      

      • 使用实际处理程序和探测代码

      private Future<SimpleHttpResponse> getHTTPResponse(String url, CloseableHttpAsyncClient httpclient, CountDownLatch latch, long startTime, SimpleHttpRequest req) {
                  return httpclient.execute(req, getHttpContext(), new FutureCallback<SimpleHttpResponse>() {
      
                      @Override
                      public void completed(SimpleHttpResponse response) {
                          latch.countDown();
                          logger.info("[{}][{}ms] - {}", response.getCode(), getTotalTime(startTime), url);
                      }
      
                      @Override
                      public void failed(Exception e) {
                          latch.countDown();
                          logger.error("[{}ms] - {} - {}", getTotalTime(startTime), url, e);
                      }
      
                      @Override
                      public void cancelled() {
                          latch.countDown();
                          logger.error("[{}ms] - request cancelled for {}", getTotalTime(startTime), url);
                      }
      
                  });
              }
      

      • 有没有一种方法可以配置客户端，使其能够在不显式修改每个endpoint上下文的配置的情况下自己处理这些差异

Answer 1

（或至少是稳定的）

HttpAsyncClients.custom()
    .setConnectionManager(manager)
    .setRetryStrategy(getRetryStrategy())
    .setVersionPolicy(HttpVersionPolicy.FORCE_HTTP_1)
    .setConnectionManagerShared(true);

• 特别是关闭标头
  • req.set标头（连接，关闭，TE）；
  • 注意：不活动检查有帮助，但有时仍然会被拒绝
  • 将帖子设置为在不活动后立即验证
    • 注：两者都使用1000会导致某些系统的高下降率

    PoolingAsyncClientConnectionManagerBuilder
        .create()
        .setValidateAfterInactivity(TimeValue.ofMilliseconds(0))
    

    • 设置GET在1s后验证

    PoolingAsyncClientConnectionManagerBuilder
        .create()
        .setValidateAfterInactivity(TimeValue.ofMilliseconds(1000))
    

    • 跟踪stacktrace到AbstractH2StreamMultiplexer中的连接问题

     if (connState == ConnectionHandshake.GRACEFUL_SHUTDOWN) {
        throw new H2StreamResetException(H2Error.PROTOCOL_ERROR, "Stream refused");
    }
    

    • 对应于

    connState = streamMap.isEmpty() ? ConnectionHandshake.SHUTDOWN : ConnectionHandshake.GRACEFUL_SHUTDOWN;
    

    • 如果我理解正确：
      • 连接未被/故意关闭
        • 然而，在再次执行之前，它们没有被确认准备好
        • 这导致它失败，因为流不可行
        • 给定强制HTTP1允许管理单个上下文
        • 通过合理的周期性检查GET的有效性

        将接受这一点，直到出现更好的答案，因为这是稳定但次优的。