powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Java [игнор отключен] [закрыт для гостей] / странное поведение AsyncContext
20 сообщений из 45, страница 2 из 2
странное поведение AsyncContext
    #39030068
Atum1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123Atum1Petro123, спасибо
я как раз привел такой пример выше ,как вариант :
не вижу.
.

Work.add(request.startAsync());

...

public void run() {
while (true) {
...
а далее разгружаем очередь

while ((context = queue.poll()) != null)

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
public void contextInitialized(ServletContextEvent servletContextEvent) {
    thread = new Thread(new Runnable() {
      @Override
      public void run() {
        while (true) {
          try {
            Thread.sleep(2000);
            AsyncContext context;
            while ((context = queue.poll()) != null) {
...
Рейтинг: 0 / 0
странное поведение AsyncContext
    #39030069
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123- везде выкинуть Thread
если ты изучаешь потоки, тогда удачи.
Тут они не нужны. Они уже есть в контейнере, в БД, в коннекте к БД, в отчётной системе и т.д.
...
Рейтинг: 0 / 0
странное поведение AsyncContext
    #39030070
Atum1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Atum1
Сразу тогда архитектурный вопрос

Это будет правильно если организовать цепочку так :
LookupService - это асинхронная работа ...
далее идет
FacadeLookupService - Это простая обертка для контроллера в котором просто идет вызов

result.get()





Код: java
1.
2.
3.
public interface LookupService {
    public Future<String> findPage() throws InterruptedException;
}



Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
@Service("lookupService")
public class LookupServiceImpl implements LookupService {
    @Async
    @Override
    public Future<String> findPage() throws InterruptedException {

        Thread.sleep(500);
        double r = Math.random();
        System.out.println("findPage" + r);
        if (r > 0.5) {
            throw new NullPointerException("test");
        }
            return new AsyncResult<>(String.valueOf(Math.random()));
    }



Код: java
1.
2.
public interface FacadeLookupService {
    public void findPageAsync(DeferredResult<String> result) throws InterruptedException ,ExecutionException; 



Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
@Service("facadeLookupService")
public class FacadeLookupServiceImpl implements FacadeLookupService {

    @Autowired
    LookupService lookupService;

    @Override
    public void findPageAsync(DeferredResult<String> result) throws InterruptedException, ExecutionException {
        String res = lookupService.findPage().get();
        result.setResult(res);
    }

}



и тогда контроллер :

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
@Controller
public class RestController {

    @Autowired
    FacadeLookupService facadeLookupService;

   @RequestMapping("/hellou")
    @ResponseBody
    public DeferredResult<String> hellou() throws InterruptedException, ExecutionException {
        DeferredResult<String> deferredResult = new DeferredResult<>();
        facadeLookupService.findPageAsync(deferredResult);
        return deferredResult;

    }





Что то перемудрил c FacadeLookupService ... это все равно что просто вызвать
в контролере
Код: java
1.
2.
  Future<String> result = lookupService.findPage();
        deferredResult.setResult(result.get());



так же?

чтобы была честная асинхронность - нужно просто засунуть в метод deferredResult

так :
Код: java
1.
2.
3.
4.
public interface LookupService {
  public void findPage(DeferredResult<String> result) throws InterruptedException;
    
}



Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
@Service("lookupService")
public class LookupServiceImpl implements LookupService {

    @Async
    @Override
    public void findPage(DeferredResult<String> result) throws InterruptedException {

        Thread.sleep(500);
        double r = Math.random();
        System.out.println("findPage" + r);
        if (r > 0.5) {
            throw new NullPointerException("test");
        }

        result.setResult(String.valueOf(Math.random()));
    }



и тогда контроллер :

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
@Controller
public class RestController {

    @Autowired
    FacadeLookupService facadeLookupService;
    
    @Autowired
    LookupService lookupService;

    @RequestMapping("/hellou")
    @ResponseBody
    public DeferredResult<String> hellou() throws InterruptedException, ExecutionException {
        DeferredResult<String> deferredResult = new DeferredResult<>();
        lookupService.findPage(deferredResult);
        return deferredResult;

    }
...
Рейтинг: 0 / 0
странное поведение AsyncContext
    #39030072
Atum1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123Petro123- везде выкинуть Thread
если ты изучаешь потоки, тогда удачи.
Тут они не нужны. Они уже есть в контейнере, в БД, в коннекте к БД, в отчётной системе и т.д.

Нужно больше потоков :)

ps

спасибо , так и буду делать - выкину все .
...
Рейтинг: 0 / 0
странное поведение AsyncContext
    #39030073
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Atum1спасибо , так и буду делать - выкину все .
ты не юродствуй. Вверху ТЗ.
Если оно не подошло - скажи чем.
Если у тя учебная задача - скажи честно.
...
Рейтинг: 0 / 0
странное поведение AsyncContext
    #39030075
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Atum11. требования что отчеты должны быть онлайн .
2. кешировать нельзя .
3. одинаковых отчетов нет .
4. каждый бизнес запрос от пользователя - меняет состояние сервера - следовательно изменяться отчет .Пункты со второго по четвёртый понятны.
Пункт первый - иллюстрация того, как на ровном месте уронить любую систему.
Если я вас правильно понимаю, то пользователи "не хотят долго ждать". Рекомендую п(р)очитать "Мифический человеко-месяц" - там и про это есть.

Теперь о последствиях странных желаний.
Сервер отчётов принимает запрос и выполняет его столько времени, сколько он его выполняет.
Если клиент вместо того, чтобы дождаться формирования запрошенного отчёта забивает на результат и отправляет новый запрос, то через короткое время сервер отчётов будет загружен запросами, которые уже никому не требуется. Могу и дальше объяснять, но, вроде, и так всё очевидно.

Самое хреновое, что ружьё может выстрелить не только в третьем акте, но и в любой момент.
Достаточно, чтобы время формирования отчётов чуть выросло: вчера было на десятую секунды ниже порога, сегодня - на десятую секунду выше и всё - приплыли. Всё стоИт кОлом и никто ничего не понимает потому, что нигде нет никаких ошибок.

И это не просто теория - в моей практике аналогичные сценарии реализовывались на практике И не с отчётами - там болячкой была пятисотая ошибка на длительных отчётах.
И хотя у меня и у разработчиков были разные взгляды на причины, могу обоснованно предположить, что я был прав.

Если я неправ и "должны быть онлайн" это простое "нельзя кэшировать", то клиент должен ждать и ограничивает его только HTTP-таймаут на ожидание заголовка ответа. И вот если не дождался - перенаправление.
Асинхронность вам полезна, но совсем не так, как вы пытаетесь нагородить.
Если в рамках Servlet API, то делается два отдельных метода:
1. doGet/doPost, который читает запрос и может:
1.1 сделать перенаправление;
1.2 вернуть готовый результат.

2. run, в котором запрашивается отчёт и который:
1.1 или возвращает результат клиенту;
1.2 или помещает его туда, откуда его вернёт 1.2.

Для синхронизации требуется два флага:
1. "Отчёт не готов" - разрешает сделать перенаправление;
2. "Перенаправление" - запрещает методу run возвращать результат клиенту, т.к. уже делается перенаправление.
Ну и тривиальные wait/notify.
...
Рейтинг: 0 / 0
странное поведение AsyncContext
    #39030076
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorov1.2 вернуть готовый результатразрешить вернуть готовый результат.
...
Рейтинг: 0 / 0
странное поведение AsyncContext
    #39030077
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovBasil A. Sidorov1.2 вернуть готовый результатразрешить вернуть готовый результат
...
Рейтинг: 0 / 0
странное поведение AsyncContext
    #39030078
Atum1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123Atum1спасибо , так и буду делать - выкину все .
ты не юродствуй. Вверху ТЗ.
Если оно не подошло - скажи чем.
Если у тя учебная задача - скажи честно.

без юродства - все нормально . просто будет переработка исходного ТЗ и сервера отчетов ... а дальше будем думать ...

спасибо за план действий ... думаю так и поступлю ( можно создать расписания + складывать все в базу , не совсем может и честно по отношению к пользователям ...но учитывая что сервер отчетов не может отдать всем все и сразу онлайн , решение нормальное, как временное сойдет)

Другой вопрос :
по коду Да это честная асинхронность - создается SimpleAsyncTaskExecutor -3 все честно ...

но при возниковении ошибки NullPointerException - она никем не обрабатывается ... :(

клиент ничего не получает в бразуре - пустота - потом 503

т.е.
в случае такой схемы и асинхронности - никто не может перехватить эту ошибку - если она возникла при выполнении метода ...

как быть ? то ? к примеру возникла неизвестная ошибка - и как нам тогда переписать метод его сигнатуру чтобы он кем то отлавливался ???

до контроллера NullPointerException не долетел ... где то внутрях умер ...


Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
@ControllerAdvice
public class ExceptionHandlerController {
    
       
    @ExceptionHandler({InterruptedException.class,
        ExecutionException.class
    })
    ResponseEntity<String> handelConflicts(Exception e) {
        System.out.println("handelConflicts ");
        return new ResponseEntity<>(e.getMessage(), HttpStatus.INTERNAL_SERVER_ERROR);
    }
    
    
    @ExceptionHandler(Exception.class)
    ResponseEntity<String> handelException(Exception e) {
        return new ResponseEntity<>(e.toString(), HttpStatus.INTERNAL_SERVER_ERROR);
    }
}






Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
чтобы была честная асинхронность - нужно просто засунуть в метод deferredResult

так : 
public interface LookupService {
  public void findPage(DeferredResult<String> result) throws InterruptedException;
    
}


@Service("lookupService")
public class LookupServiceImpl implements LookupService {

    @Async
    @Override
    public void findPage(DeferredResult<String> result) throws InterruptedException {

        Thread.sleep(500);
        double r = Math.random();
        System.out.println("findPage" + r);
        if (r > 0.5) {
            throw new NullPointerException("test");
        }

        result.setResult(String.valueOf(Math.random()));
    }


и тогда контроллер : 

@Controller
public class RestController {

    @Autowired
    FacadeLookupService facadeLookupService;
    
    @Autowired
    LookupService lookupService;

    @RequestMapping("/hellou")
    @ResponseBody
    public DeferredResult<String> hellou() throws InterruptedException, ExecutionException {
        DeferredResult<String> deferredResult = new DeferredResult<>();
        lookupService.findPage(deferredResult);
        return deferredResult;

    } 
...
Рейтинг: 0 / 0
странное поведение AsyncContext
    #39030079
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorov,
+1
а ожидание флага как параметр или чем регулируем?
...
Рейтинг: 0 / 0
странное поведение AsyncContext
    #39030080
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123а ожидание флага как параметр или чем регулируем?Можно прочитать спеки и зашить в коде "не более двух минут".
Можно сказать "Две минуты - жестоко" и долго выбирать в диапазоне от пяти до пятнадцати секунд.
Можно сказать "Сами выбирайте" и сделать параметр в контексте, который init() вычитает, подкорректирует, если он будет менее пяти секунд или долее двух минут. При корректировке - логировать сообщение, чтобы никто потом не удивлялся.
...
Рейтинг: 0 / 0
странное поведение AsyncContext
    #39030082
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кстати, насчёт "две минуты" неправ - отклик сервера ждётся дольше.
Тогда, если формирование отчётов укладывается в десять минут - вообще никакой асинхронности не требуется. Клиент отправляет запросы и ждёт ответ в фоновом режиме, чтобы "не морозить" интерфейс и сам оповещает пользователя о готовности отчёта.
Если "правильное решение" невозможно или отчёты "долго формируются" - тогда перенаправление и асинхронность, как способ упрощения кода.
...
Рейтинг: 0 / 0
странное поведение AsyncContext
    #39030083
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorov,
+1
У фокса на AJAX вроде по умолчанию 300 сек на ответ от сервера AFAIK.
Если сделать прозрачно + логирование + статистика на видном месте (доска почёта )) ), то пользователи поймут))).
...
Рейтинг: 0 / 0
странное поведение AsyncContext
    #39030089
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кстати вариант который обсуждали подходит?
- Клиент по AJAX jQuery отправляет запрос с флагом асинхронно (чтобы не морозить ГУИ).
В каллбэк этого запроса на клиенте в период 300сек приходит ответ от сервлета по отчёту.
Там может стоять хоть alert('Готово'); хоть редирект на сервлет с он-лайн потоком отчёта.
Тоже никаких потоков и асинхронности не надо.
Да, если будет более 300 сек, то будет ошибка на экране "сервер занят".
Но ведь писать то ничего не надо. Это можно к вечеру внедрить и отписаться тут на форуме.
Это вроде то что сказал Basil A. Sidorov.
IMHO
...
Рейтинг: 0 / 0
странное поведение AsyncContext
    #39030090
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorov2. run, в котором запрашивается отчёт и который:
1 2.1 или возвращает результат клиенту;
1 2.2 или помещает его туда, откуда его вернёт 1.2.
...
Рейтинг: 0 / 0
странное поведение AsyncContext
    #39030092
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вот, то о чём говорили коротко и ясно:
https://toster.ru/q/156091
relgames @relgames Самый важный вопрос - хотите ли вы синхронный или асинхронный API?

При синхронном, пользователь отправляет запрос и ожидает ответа в этом же HTTP вызове.
Прогресс можно писать прямо в output stream сервлета, но нужно договориться о протоколе.
Например, писать строки вида STATUS REPORT: 80%, а клиент должен уметь различать такие строки от настоящих данных.

Если запрос разорвется, то должен быть механизм подключения к той же задаче. Это довольно сложно, но реально. Например, можно первым делом генерить некий ID и выдавать его в первых строках, и если соединение рвется, клиент может переподключиться с этим же ID.

При асинхронном API генерируется ID, задача ставится в очередь, а клиент получает этот ID и HTTP вызов завершается. Потом клиент должен периодически опрашивать уже другой API (например, getResult(id) ), и если результата еще нет, этот API может возвращать что-то типа "NOT READY, STATUS 85%" в хедерах.

Подходы можно комбинировать - запуск задачи может быть асинхронным, а getResult - синхронным.

Конкретная реализация зависит от многих факторов. Можно просто в Executor добавлять задачу, а статус писать в какую-нибудь очередь. Можно на JMS делать. Можно вообще другой процесс запускать и общаться с ними через std in/out.
интересен метод посылки частичного результата в запрос)).
...
Рейтинг: 0 / 0
странное поведение AsyncContext
    #39030103
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Человек пишет прокси.
Если проксируемый ресур не умеет сообщать "проценты выполнения", то всякие прогресс-бары должны делаться на клиенте. И десять против одного, что не умеет.
...
Рейтинг: 0 / 0
странное поведение AsyncContext
    #39030133
Atum1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123Кстати вариант который обсуждали подходит?
- Клиент по AJAX jQuery отправляет запрос с флагом асинхронно (чтобы не морозить ГУИ).
В каллбэк этого запроса на клиенте в период 300сек приходит ответ от сервлета по отчёту.
Там может стоять хоть alert('Готово'); хоть редирект на сервлет с он-лайн потоком отчёта.
Тоже никаких потоков и асинхронности не надо.
Да, если будет более 300 сек, то будет ошибка на экране "сервер занят".
Но ведь писать то ничего не надо. Это можно к вечеру внедрить и отписаться тут на форуме.
Это вроде то что сказал Basil A. Sidorov.
IMHO

Да сейчас именно так и работает.

Но это не спасает от ddosa сервер отчетов.
...
Рейтинг: 0 / 0
странное поведение AsyncContext
    #39030157
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Atum1,
Т.е. 5 минут они ждут Отчёт и он не готов?
DDOS это когда вредители.
Тогда второй вариант:авторПри асинхронном API генерируется ID, задача ставится в очередь, а клиент получает этот ID и HTTP вызов завершается. Потом клиент должен периодически опрашивать уже другой API (например, getResult(id) ), и если результата еще нет, этот API может возвращать что-то типа "NOT READY, STATUS 85%" в хедерах.
Пусть заходят и берут свой отчёт хоть завтра, хоть сидя на стуле и читая сообщение "Жди..жди, я работаю".
Удачи!
...
Рейтинг: 0 / 0
странное поведение AsyncContext
    #39030564
Atum1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вот , как мне показалось нормальный вариант через расписание в контроллере :

тут только выбор между fixedDelay или fixedDelay (один поток и ждет или не ждет ).
Ну и проблема с ошибкой , которая возникает внутри метода осталась ...

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
 @Controller
public class RestController {

    @Autowired
    FacadeLookupService facadeLookupService;
    
    @Autowired
    LookupService lookupService;


....

    private final Queue<DeferredResult<String>> responseBodyQueue = new ConcurrentLinkedQueue<>();

    @RequestMapping("/hellom")
    @ResponseBody
    public DeferredResult<String> hellom() throws InterruptedException, ExecutionException {
        DeferredResult<String> deferredResult = new DeferredResult<>();
        responseBodyQueue.add(deferredResult);
        return deferredResult;
    }

    @Scheduled(fixedRate = 1000) //TODO  fixedDelay =  для 1 потока
    public void processQueues() throws InterruptedException, ExecutionException {
        System.out.println("processQueues :" + responseBodyQueue.size());
        for (DeferredResult<String> deferredResult : responseBodyQueue) {
            Future<String> result = lookupService.findPage();
            deferredResult.setResult(result.get());
            responseBodyQueue.remove(deferredResult);
        }
        
    }
...
Рейтинг: 0 / 0
20 сообщений из 45, страница 2 из 2
Форумы / Java [игнор отключен] [закрыт для гостей] / странное поведение AsyncContext
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]