|
|
|
странное поведение AsyncContext
|
|||
|---|---|---|---|
|
#18+
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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2015, 18:33 |
|
||
|
странное поведение AsyncContext
|
|||
|---|---|---|---|
|
#18+
Petro123- везде выкинуть Thread если ты изучаешь потоки, тогда удачи. Тут они не нужны. Они уже есть в контейнере, в БД, в коннекте к БД, в отчётной системе и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2015, 18:38 |
|
||
|
странное поведение AsyncContext
|
|||
|---|---|---|---|
|
#18+
Atum1 Сразу тогда архитектурный вопрос Это будет правильно если организовать цепочку так : LookupService - это асинхронная работа ... далее идет FacadeLookupService - Это простая обертка для контроллера в котором просто идет вызов result.get() Код: java 1. 2. 3. Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Код: java 1. 2. Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. и тогда контроллер : Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Что то перемудрил c FacadeLookupService ... это все равно что просто вызвать в контролере Код: java 1. 2. так же? чтобы была честная асинхронность - нужно просто засунуть в метод deferredResult так : Код: java 1. 2. 3. 4. Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. и тогда контроллер : Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2015, 18:39 |
|
||
|
странное поведение AsyncContext
|
|||
|---|---|---|---|
|
#18+
Petro123Petro123- везде выкинуть Thread если ты изучаешь потоки, тогда удачи. Тут они не нужны. Они уже есть в контейнере, в БД, в коннекте к БД, в отчётной системе и т.д. Нужно больше потоков :) ps спасибо , так и буду делать - выкину все . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2015, 18:40 |
|
||
|
странное поведение AsyncContext
|
|||
|---|---|---|---|
|
#18+
Atum1спасибо , так и буду делать - выкину все . ты не юродствуй. Вверху ТЗ. Если оно не подошло - скажи чем. Если у тя учебная задача - скажи честно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2015, 18:43 |
|
||
|
странное поведение AsyncContext
|
|||
|---|---|---|---|
|
#18+
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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2015, 18:52 |
|
||
|
странное поведение AsyncContext
|
|||
|---|---|---|---|
|
#18+
Basil A. Sidorov1.2 вернуть готовый результатразрешить вернуть готовый результат. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2015, 18:55 |
|
||
|
странное поведение AsyncContext
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovBasil A. Sidorov1.2 вернуть готовый результатразрешить вернуть готовый результат ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2015, 18:56 |
|
||
|
странное поведение AsyncContext
|
|||
|---|---|---|---|
|
#18+
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. Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2015, 18:58 |
|
||
|
странное поведение AsyncContext
|
|||
|---|---|---|---|
|
#18+
Basil A. Sidorov, +1 а ожидание флага как параметр или чем регулируем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2015, 18:58 |
|
||
|
странное поведение AsyncContext
|
|||
|---|---|---|---|
|
#18+
Petro123а ожидание флага как параметр или чем регулируем?Можно прочитать спеки и зашить в коде "не более двух минут". Можно сказать "Две минуты - жестоко" и долго выбирать в диапазоне от пяти до пятнадцати секунд. Можно сказать "Сами выбирайте" и сделать параметр в контексте, который init() вычитает, подкорректирует, если он будет менее пяти секунд или долее двух минут. При корректировке - логировать сообщение, чтобы никто потом не удивлялся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2015, 19:08 |
|
||
|
странное поведение AsyncContext
|
|||
|---|---|---|---|
|
#18+
Кстати, насчёт "две минуты" неправ - отклик сервера ждётся дольше. Тогда, если формирование отчётов укладывается в десять минут - вообще никакой асинхронности не требуется. Клиент отправляет запросы и ждёт ответ в фоновом режиме, чтобы "не морозить" интерфейс и сам оповещает пользователя о готовности отчёта. Если "правильное решение" невозможно или отчёты "долго формируются" - тогда перенаправление и асинхронность, как способ упрощения кода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2015, 19:19 |
|
||
|
странное поведение AsyncContext
|
|||
|---|---|---|---|
|
#18+
Basil A. Sidorov, +1 У фокса на AJAX вроде по умолчанию 300 сек на ответ от сервера AFAIK. Если сделать прозрачно + логирование + статистика на видном месте (доска почёта )) ), то пользователи поймут))). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2015, 19:19 |
|
||
|
странное поведение AsyncContext
|
|||
|---|---|---|---|
|
#18+
Кстати вариант который обсуждали подходит? - Клиент по AJAX jQuery отправляет запрос с флагом асинхронно (чтобы не морозить ГУИ). В каллбэк этого запроса на клиенте в период 300сек приходит ответ от сервлета по отчёту. Там может стоять хоть alert('Готово'); хоть редирект на сервлет с он-лайн потоком отчёта. Тоже никаких потоков и асинхронности не надо. Да, если будет более 300 сек, то будет ошибка на экране "сервер занят". Но ведь писать то ничего не надо. Это можно к вечеру внедрить и отписаться тут на форуме. Это вроде то что сказал Basil A. Sidorov. IMHO ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2015, 19:39 |
|
||
|
странное поведение AsyncContext
|
|||
|---|---|---|---|
|
#18+
Basil A. Sidorov2. run, в котором запрашивается отчёт и который: 1 2.1 или возвращает результат клиенту; 1 2.2 или помещает его туда, откуда его вернёт 1.2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2015, 19:44 |
|
||
|
странное поведение AsyncContext
|
|||
|---|---|---|---|
|
#18+
вот, то о чём говорили коротко и ясно: 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. интересен метод посылки частичного результата в запрос)). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2015, 19:52 |
|
||
|
странное поведение AsyncContext
|
|||
|---|---|---|---|
|
#18+
Человек пишет прокси. Если проксируемый ресур не умеет сообщать "проценты выполнения", то всякие прогресс-бары должны делаться на клиенте. И десять против одного, что не умеет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2015, 20:36 |
|
||
|
странное поведение AsyncContext
|
|||
|---|---|---|---|
|
#18+
Petro123Кстати вариант который обсуждали подходит? - Клиент по AJAX jQuery отправляет запрос с флагом асинхронно (чтобы не морозить ГУИ). В каллбэк этого запроса на клиенте в период 300сек приходит ответ от сервлета по отчёту. Там может стоять хоть alert('Готово'); хоть редирект на сервлет с он-лайн потоком отчёта. Тоже никаких потоков и асинхронности не надо. Да, если будет более 300 сек, то будет ошибка на экране "сервер занят". Но ведь писать то ничего не надо. Это можно к вечеру внедрить и отписаться тут на форуме. Это вроде то что сказал Basil A. Sidorov. IMHO Да сейчас именно так и работает. Но это не спасает от ddosa сервер отчетов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2015, 22:24 |
|
||
|
странное поведение AsyncContext
|
|||
|---|---|---|---|
|
#18+
Atum1, Т.е. 5 минут они ждут Отчёт и он не готов? DDOS это когда вредители. Тогда второй вариант:авторПри асинхронном API генерируется ID, задача ставится в очередь, а клиент получает этот ID и HTTP вызов завершается. Потом клиент должен периодически опрашивать уже другой API (например, getResult(id) ), и если результата еще нет, этот API может возвращать что-то типа "NOT READY, STATUS 85%" в хедерах. Пусть заходят и берут свой отчёт хоть завтра, хоть сидя на стуле и читая сообщение "Жди..жди, я работаю". Удачи! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2015, 23:31 |
|
||
|
странное поведение AsyncContext
|
|||
|---|---|---|---|
|
#18+
Вот , как мне показалось нормальный вариант через расписание в контроллере : тут только выбор между 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2015, 09:50 |
|
||
|
|

start [/forum/topic.php?fid=59&gotonew=1&tid=2125045]: |
0ms |
get settings: |
12ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
184ms |
get topic data: |
7ms |
get first new msg: |
4ms |
get forum data: |
1ms |
get page messages: |
36ms |
get tp. blocked users: |
1ms |
| others: | 268ms |
| total: | 530ms |

| 0 / 0 |
