давай покажи

вообще то тут число потоков неизвестно.
на данный момент 3 просто взято для тестов, если взять 1 а, запустить 2 обращения - будет ошибка.

пока факт работы - подтверждает правильность пути - надо запускать в отдельных потоках.
я ещё в начальных страницах предлагал вот этот метод
Bot.DFL_control.DFL_set_IP(dfl_host, dfl_home_name, dfl_IPRuleFolder, mc[0]);
запускать в отдельном потоке, т.е. не зависимо от того что там запущено организовывать новый поток и его там запускать. вот только вопрос был -как обеспечить синхронизацию этих методов между собой?
если в одном потоке то синхронизация должна разлулить это сама?

тут дело не в асинхронных сервлетах.

если взять обыкновенный сайт - и два обыкновенных клиента обратятся к этому сервлету - они получат первое сообщение сразу, но будет проблема когда они обратятся к методу Bot.DFL_control.DFL_set_IP

их надо ставить либо в очередь, либо как-то синхронизировать

и есть ситуация когда это вариант и вариант с телеграм работают вместе
метод Bot.DFL_control.DFL_set_IP может вызываться как выше показано так и из некоторых jsp страниц

метод Bot.DFL_control.DFL_set_IP должен работать только в одном экземпляре в любой момент времени

как лучше это организовать?

странный ты, видимо ты из тех кто "... не читал, но осуждаю..."
не зная тонкости проблемы говорить всякую ерунду.
железо - роутер. ему передаётся ip, и прочая инфа. и даётся команда - сохранить . "сохранить" это значит записать в пзу. процесс записи 15сек. и ты хоть что делай - пока пишется - новый процесс записи организовать не возможно. можно записывать данные для одного юзера, а можно и для 10 - только вопрос сколько ждать после прихода данных от первого юзера до прихода от второго? 1 секунду? 20? 5? чтоб их одновременно записать.
тот вариант что работает - не устраивал тем, что второй юзер дал команду и не получает быстрого ответа (реакции) от системы (в отличии от того когда он был первым) и начинает волноваться, совершать не нужные действия - а реакция системы - ответ "ждите".
вероятность таких обращений 1-2 в день и то не каждый.
ели поставить вместо роутера севачок с iptebles - таких проблем не будет. но обслуживание системника и коробочки- разные вещи.
так что:

это относится к тебе.

дело в том, что юзер в телеграм передаёт свой ip, и ждёт когда ему будет дано разрешение на подключение по rdp с этого ip.
вот с помощью запуска записи в отдельном потоке и получится - отдельно

PetroNotC Sharp,

ты вообще знаком как работает telegram?
возьмём к примеру на смартфоне - это приложение
оно подключено к серверу TELEGRAM, который находится хер знает где
клиент - на смартфоне в приложении телеграм что-то набирает (возможны варианты -текс и команды, нас интересуют только команды, команда начинается с / )
и отправляет это сервере телеграм, это происходит в так называемом боте.
ну и так далее....

сервер телеграм отправляет (переправляет) эти сообщения моему серверу - тут есть 2 варианта - вебхук и лонгполлинг
для приема по вебхуку я использую сервлет.
@WebServlet(name = "WebhookBot", urlPatterns = {"/pagebot"})
public class WebhookBot extends HttpServlet {




от сервера телеграм приходит много видов сообщений в doPost происходит частичная выборка информации
эта информация передаётся в метод Update_id Б который находится в этом сервлете


в методе Update_id происходит дальнейшая обработка и вызывается
метод ip из класса IP


в методе ip вызывается метод Bot.DFL_control.DFL_set_IP из соответствующего класса

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


сервер телеграм имеет доступ к моему серверу только в одной сессии . сообщения шлются по очереди.

дальше разжёвывать?

PetroNotC Sharp,

если тебе будет более понятно можно изобразить так

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

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