Здравствуйте, уважаемые.

У меня тут щепетильная ситуация... Сначала искал возможности для асинхронной работы с удаленными компами, нашел, а теперь не могу сделать синхронную работу...



ответные сообщения идут от соединений вот так:



Думал сделать так:





Все бы ничего но для каждого синхронизированного запроса так изголяться?! уж тяжело даже мне. Благо пока 1 такой метод, но если поставить на массовый поток клепание синхронизированых методов?

Я явно упустил какой-то легкий подход.


Это сообщение отредактировал(а) Platon - 23.1.2008, 12:03

Кстати вот мой объект, ожидающий ответа:


Но, боюсь, что если более 1 запроса будет ожидать обработки, то могут возникнуть разного рода проблемы?
К примеру, в сокет отправилось 2 запроса о проверке наличия пользователя, и как я вижу, 2 потока лягут спать на объекте ResponseWaitor и при обращении к методу ResponseWaitor.notify() неизвестно какой поток пробудится...

Я делал так:
- один поток обрабатывал сеть (отправлял и получал оттуда данные)
- другие потоки вызывали методы этого объекта для отправки данных
- когда метод хотел синхронно отправить сообщение, объект работающий с потоком обработки сети отправлял данные, записывал в что ожидается ответ на сообщение с таким-то ID, и усыплял поток
- когда приходило сообщение, проверял что это подтверждение, будил все потоки и у каждого проверял, что это сообщение для него, нужный поток получал управление обратно и ответ, а все остальные снова засыпали дальше

Что-то ты и правда намудрил. Попробуй описать задачу целиком - может найдется просто иное решение. Проще и "стандартнее".

LSD, ну на самом деле не намного проще получается :( или я просто не понял.


AntonSaburov, использую библиотеку Apache MINA для организации сети.
Задача: оформить синхронизированную работу функций.
Вот я накидал как оно выглядит
Клиентская часть


Серверная часть


Главная загвоздка находится в классе ServerConnection, как раз там необходимо усыплять потоки.

Вообщем да. В любом случае проблема состоит в том, что надо усыплять поток до тех пор пока не придёт ответ. Хотя тут код получится не такой уж чтобы сверх сложный.

Хм, странно, попробовал потестировать со своим ResponseWaitor'ом тест прошел, глюков и дедлоков не было... надо думать что всё таки так дело нормально пройдет, проверим еще на нескольких тачках.

Очевидно, вы хотите синхронные запросы пропускать через один канал связи, т.е. через один сокет. Это неестественно. Натурально будет, если для синхронного запроса открыть новое соединение, получить ответ и закрыть соединение. Используя асинхронный канал для синхронных запросов вы получаете свои трудности:
 - иметь коллекцию, где потоки запросов будут ожидать ответа, 
 - иметь таймер, который мониторит коллекцию и выбрасывает потоки, у которых задержка ответа превышает таймаут, 
 - в каждом запросе отправлять уникальный ID запроса
 - в каждом ответе на запрос возвращать ID запроса, чтобы отыскать поток в коллекции и разбудить его.  

Ну, уж так уж натурально?
видимо с ID придется бегать...

Ты главное потоков побольше запусти, и дольше тестируй.

P.S. У меня там ещё тайм аут обрабатывался. А у тебя как с этим? 

На самом деле никак. Я еще вечерком подумаю над тем что мне насоветовали ^_^

именно так, потому что не надо синхронную схему приспосабливать к асинхронному каналу связи - никаких ID, коллекций, таймеров и блоков синхронизаций.  

COVD, это уже получается сервис? но это соединение также обслуживает асинхронные запросы.

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

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

Это сообщение отредактировал(а) COVD - 23.1.2008, 18:56

Ок, логичное решение... не догадался.
НО, вот будет утомительно плясать вокруг каждого такого метода...

Каков же опыт RMI, на сколько я знаю там все методы сделаны в синхронном стиле. но нам плясать никак не надо. Может быть этот опыт можно повзаимствовать или придется все методы делать синхронными.