Потоки в Apache Tomcat
У меня вопрос, чем это грозит и есть ли альтернативные java технологии (помимо Treads) лучше всего подходящие для данной задачи?Задача слишком общая. Не ясно, при чём тут Apache Tomcat. Синхронный сервлет уже вызывается в отдельном потоке. Проще всего использовать не потоки напрямую, а Executors.
Tomcat выбран как веб-сервер, вот и вопрос, возможно есть подводные камни на этом этапе.
Вопрос не про проще, а про эффективнее.
Вопрос не про проще, а про эффективнее.
скилл телепата подсказывает, что на базе томкета будет развернут веб-сервис через спринг
этот веб-сервис, при формировании ответа клиентам, будет стучаться к двум другим серверам, получать с них ответ, и только после этого отвечать своему клиенту
подводный камень очень прост - если запросов к вам будет приходить много, а внешние веб-сервисы тупят - то треды быстро кончатся
решается проблема использованием асинхронного ввода-вывода - как для обслуживания клиентов, так и для выполнения запросов к внешним сервисам.
если больше сотни одновременных запросов не предвидится, и внешние сервисы в_локалке/не_тупят - то можно и забить
этот веб-сервис, при формировании ответа клиентам, будет стучаться к двум другим серверам, получать с них ответ, и только после этого отвечать своему клиенту
подводный камень очень прост - если запросов к вам будет приходить много, а внешние веб-сервисы тупят - то треды быстро кончатся
решается проблема использованием асинхронного ввода-вывода - как для обслуживания клиентов, так и для выполнения запросов к внешним сервисам.
если больше сотни одновременных запросов не предвидится, и внешние сервисы в_локалке/не_тупят - то можно и забить
Проблема с тупящими внешними сервисами решена. Клиент не ждет ответа от сервиса, а получается id задачи, а через время спрашивает есть ли ответ.
Вот можно подробнее про "треды быстро кончатся". Вот если треды кончатся при подключениях пользователей, то они также могу кончится при создании тредов для взаимодействия с внешними сервисами.
Вот можно подробнее про "треды быстро кончатся". Вот если треды кончатся при подключениях пользователей, то они также могу кончится при создании тредов для взаимодействия с внешними сервисами.
Вот можно подробнее про "треды быстро кончатся". Вот если треды кончатся при подключениях пользователей, то они также могу кончится при создании тредов для взаимодействия с внешними сервисами.Новый поток в любой ОС жрет какое-то кол-во ресурсов - немного памяти и немного цпу для его планирования.
Соответственно, когда становится много потоков, во-первых, может или кончиться ядреная память, или вы упретесь в какой-нибудь лимит ОС, и не сможете больше создавать новых потоков, пока не сдохнут старые.
Во-вторых, начнет ощутимо тупить скедулер, не очень любящий большое кол-во потоков.
Вышеозначенные проблемы начинаются от кол-ва живых тредов порядка 10^4-10^5.
Стандартное решение для выполнения очереди задач в многопоточной среде - клац.
>Новый поток в любой ОС жрет какое-то кол-во ресурсов - немного памяти и немного цпу для его планирования.
Потоки jvm не обязаны быть потоками ОС, насколько я помню.
Потоки jvm не обязаны быть потоками ОС, насколько я помню.
Честно говоря, не знаю, что там по спеку (и искать лень) - вполне возможно, что не обязаны, да.
Тем не менее, если вдруг jvm потоки не будут зависеть от нативных потоков, это будет всего лишь значить, что расходы памяти и планировки уйдут в jvm.
И все те же проблемы будут возникать, просто не на уровне ос, а на уровне jvm.
Чудес не бывает.
я к тому, что слова "в любой ОС" не нужны, ОС может вообще не поддерживать треды, а в jvm они будут.
Порекомендовали смотреть в сторону спринговского @Async и JMS, что скажите?
Не фанат спринга, поэтому @Async не могу прокомментировать. А JMS - явный overkill.
@Async - это прозрачный асинхронный вызов в тредпуле, вроде даже с очередью, если тредов не хватит.
Спасибо за помощь.
Может у кого есть идеи или кто сталкивался.как вариант пишите специальный proxy-скрипт и кладёте его к себе же на хост
proxy-скрипт должен уметь, в зависимости от параметров, работать с нужным партнёрами
вызов этого proxy-скрипта осуществляется средствами curl_multi
Кажется это не хорошо, писать скрипт, когда есть Java и куча технологий, которые могут решить данную задачу.
я, как обычно, привёл пример, как это сделано у нас на php
Оставить комментарий
t1h0n0ff
Есть задача.Создать веб-сервис, используя Spring MVC(отказался от spring-ws и jaxb-ws общаться будет xml сообщениями.
После проектирования сервиса пришли к выводу что в одном месте лучше всего будет использовать потоки, то есть для каждого запроса к сервису нужно будет создавать (пока!) 2 потока, чтобы он параллельно отрабатывали.
У меня вопрос, чем это грозит и есть ли альтернативные java технологии (помимо Treads) лучше всего подходящие для данной задачи?
Потоки ничего сложного не считают, они работаю с двумя внешними информационными системами, то есть по сути такими же веб-сервисами. Вся работа заключается: сформировать запрос, отправить, получить ответ (иногда большой ответ разобрать ответ.
Может у кого есть идеи или кто сталкивался.