#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, который я пробовал, но не смог найти способ сделать