Прерывание, если вызов API для платежного процессора занимает более 60 секунд

#java #multithreading #jersey #thread-safety

#java #многопоточность #джерси #потокобезопасность

Вопрос:

Я интегрируюсь с процессором платежей и пытаюсь разобраться со сценарием, в котором:

  • пользователь нажимает оплатить, и на наш сервер отправляется запрос
  • наш сервер отправляет запрос платежному процессору
  • существует значительная задержка на стороне платежного процессора
  • по истечении определенного порога, например, 60 секунд, мы уведомляем пользователя о том, что его платеж был неудачным
  • через 70 секунд платежный процессор возвращает успешный ответ.

Итак, мне нужно запустить вызов API для платежного процессора из HTTP-вызова из пользовательского интерфейса, затем, если это займет более 60 секунд, завершите HTTP-вызов и верните ошибку пользователю, затем, если вызов API для платежного процессора в конечном итоге завершится успешно (скажем, через 70 секунд),отправьте электронное письмо команде администраторов.

Я думаю о чем-то подобном:

     import javax.ws.rs.client.*;
    import java.util.Timer;
    import java.util.TimerTask;

    ...

    boolean overThreshold = false;
    int timeout = 60; // seconds
    TimerTask task = new TimerTask() {
        @Override
        public void run() {
            overThreshold = true;
            // return a message to user here saying their payment could not be processed
        }
    };

    new Timer(true).schedule(task, timeout * 1000);

    Client client = ClientBuilder.newClient();
    WebTarget webTarget
            = client.target({url of payment processor});
    Invocation.Builder builder = webTarget.request()
            .header(HttpHeaders.CONTENT_TYPE, APPLICATION_JSON);

    final Response response = builder.post(Entity.json(new Gson().toJson(request)));

    if (overThreshold) {
        // send alert email here
    }
  

Есть несколько проблем, например run() , метод имеет возвращаемое значение void, ошибка с overThreshold as, доступ к которому осуществляется из внутреннего класса. Есть ли более элегантный способ сделать это?

Комментарии:

1. ИМО, это классический вариант использования, который должен быть реализован как реактивный сервис. Возможно, вас заинтересует что-то похожее на blog.payara.fish/ …

Ответ №1:

Использование Future.get(timeout) из ExecutorService должно справиться с этим довольно чисто.

Например:

     ExecutorService executor = Executors.newCachedThreadPool();

    // ... set up builder as before ...
    Future<Response> responseFuture = executor.submit(
            () -> builder.post(Entity.json(new Gson().toJson(request))));
    try {
        Response response = responseFuture.get(timeout, TimeUnit.SECONDS);
        // return normal response here
    } catch (TimeoutException ex) {
        executor.submit( () -> {
            Response lateResponse = responseFuture.get();
            // send overThreshold alert email here
            // Dummy return - prefer Callable to Runnable here for exception handling
            return null;
        } );
        // return a message to user here saying their payment could not be processed
    }
  

Выбор ExecutorService может быть настроен на соответствие или в равной степени быть общим пулом потоков в другом месте приложения.

Комментарии:

1. На самом деле, просто реализуя это — если я возвращаю сообщение пользователю, response = responseFuture.get(); оно никогда не будет выполнено…

2. Хороший момент. При прямом return вводе сообщения (в отличие от записи в поток ответов), самым простым способом было бы сделать последующее выполнение асинхронным. Ожидание get() и последующая отправка предупреждения о превышении порога могут произойти, когда они будут готовы. Ответ был обновлен в этих строках. Другой возможностью было бы повторно проверить, был ли отправлен ответ обратно в первом блоке, после builder.post() . Это более эффективно для подсчета количества потоков в случае сбоя, но для связи между двумя потоками потребуется немного больше общего состояния и / или синхронизации.

3. Возможно ли завершить логику кода, который вы предоставляете CompletableFuture в jdk, который я пробовал, но не смог найти способ сделать