Привет,

Вопрос простой и глупый, но не хочется городить свои велосипеды. Задача: есть специальный файл в котором записанны данные по строчкам и для каждой строчки я должен выполнить определённые действия. В данной случае одно из действий это отправка запросов на сервер (HLR) через web-service (request) и потом, через некоторое время, HLR вызывает мой notification web-service, в который передает данный об успешности/не успешности request. То есть если схематично:

line1 -> thread1 -> request1 -> ждем ответа HLR -> response1 -> продолжаем работу дальше
line2 -> thread2 -> request2 -> ждем ответа HLR -> response2 -> продолжаем работу дальше
line3 -> thread3 -> request3 -> ждем ответа HLR -> response3 -> продолжаем работу дальше
line4 -> thread4 -> request4 -> ждем ответа HLR -> response4 -> продолжаем работу дальше

Дальше у меня есть веб-сервис, в который будут приходить responses от HLR и мне нужно уведомлять потоки, которые ждут ответы от HLR о результате.

С ходу напрашивается решение: каждый поток, который отправляет request к HLR, добавляет себя в очередь ожидания, после добавления в очередь ожидания, становится в ожидание и ждет ответа от сервера. Думаю, что такое решение можно сделать с помощью списока мониторов и использования методов wait (какое-то время, что бы бесконечно не ждать сервер)/notify. Может знает кто-то стандартные API для этого или как вообще люди делают?

svenom,

Дело в том, что потоки уже созданы, то есть я посылаю request к HLR уже в существующем потоке, который должен остановиться и ждать, пока на его запрос не прийдет ответ от сервера.

На сколько я знаю эти классы Barrier, Latch, Semaphore, они работаю следующим образом: у нас есть N операций и мы ставим "стену" и "стена" будет сдерживать потоки, пока они все не отработают. В моем же случае, как только notification web-service получил ответ от HLR он должен уведомить ждущий поток о результате и поток должен продолжить работу.

HLR содержит данные о SIM-картах оператора мобильной связи

Blazkowiczsvenomто смотрите в сторону высокоуровневых вещей
+1. Или даже JMS

Слишком мальнькая проблема, что бы для нее городить JMS, нужно что-то попроще...

Blazkowicz_chaos_через некоторое время, HLR вызывает мой notification web-service, в который передает данный об успешности/не успешности request
В response?

Именно, там есть id моего request и по нему я могу определить какому потоку отдать результат.

Blazkowicz_chaos_С ходу напрашивается решение: каждый поток, который отправляет request к HLR, добавляет себя в очередь ожидания, после добавления в очередь ожидания, становится в ожидание и ждет ответа от сервера.
Ну, вообще клиенты по-умолчанию использую блокирующий IO и каждый поток засыпает, пока не придет ответ. Никаких дополнительных телодвижений для этого не нужно.

В том то и дело, что web-service работает как отправил и забудь (асинхронно). А результат прийдет в notification web-service.

svenom_chaos_На сколько я знаю эти классы Barrier, Latch, Semaphore, они работаю следующим образом: у нас есть N операций и мы ставим "стену" и "стена" будет сдерживать потоки, пока они все не отработаютЭто неверно. Вы описали работу Barrier, Latch и Semaphore это совершенно другие вещи.


Насколько я знаю, Barrier и Latch не особо отличаются по семантики, разница лишь в нескольких фичесах, например, в Barrier можно установить barrierAction, который будет вызван когда все потоки будут завершены, а также, например, можно сделать reset count-а. Про Semaphore ничего не могу сказать.

svenom_chaos_Именно, там есть id моего request и по нему я могу определить какому потоку отдать результат.Ну отлично, тогда делаете так.
1. Создаете Runnable, которому передаете некий ваш идентификатор и новый инстанс CountdownLatch:


2. Далее кладете идентификатор и latch в мапу:
latchMap.put(id, latch);
3. В теле вашего Runnable:


4. При получении ответа от HLR:


Все.

Я не хочу лезть в создание котока, потому что во-первых: он создается в ядре "системы" и не очень то и хотелось навешивать на него ещё какие-то долнительные обьекты, во-вторых: я не знаю о id в то время когда создаю поток.

Я вот не пойму, почему если сделать что-то похожее, но организовать всё через обычный монитор, то есть создать object и использовать его notify/wait. Чем это хуже чем дополнительный обьект CountDownLatch?

svenomавторBarrier и Latch не особо отличаются по семантики, разница лишь в нескольких фичесах, например, в Barrier можно установить barrierAction, который будет вызван когда все потоки будут завершены,Неверно, задачи принципиально разные. Цель барьера - обеспечить одновременный старт нескольких потоков, когда каждый из них придет достигнет определенной точки своего выполнения. Цель латча - обеспечить старт потока(потоков), после того, как другие потоки совершили некие действия. Сементика абсолютно разная.

Да точно-точно правы, немного подзабыл :).

svenom_chaos_ Я не хочу лезть в создание котока, потому что во-первых: он создается в ядре "системы" и не очень то и хотелось навешивать на него ещё какие-то долнительные обьекты, во-вторых: я не знаю о id в то время когда создаю поток.Так как вы все-таки собираетесь сопоставлять реквесты и респонсы?
Ну хотите - создайте внутри потока латч и положите его в какую-нибудь расшаренную мапу.


Можно и так.

_chaos_ Я вот не пойму, почему если сделать что-то похожее, но организовать всё через обычный монитор, то есть создать object и использовать его notify/wait. Чем это хуже чем дополнительный обьект CountDownLatch? Ок, тогда вот вам вопрос - чего будет ждать поток? Как обычно wait() используется? Вот так:
while (condition) {
monitor.wait();
}
Что у вас будет монитором? Что у вас будет condition?[/quot]
[/quot]

Ну... Допустим, у нас есть, скажем, HLRHander, который отправляет запрос к HLR и должен ждать. Дальше у нас есть, скажем, HLRNotificationPool, в который HLRHandler ложит себя и id request-а, скажем, так HLRNotificationPool.wait(this, id).

HLRNotificationPool.wait(this, id) {
obj = создаем обьект
obj.wait() - на данный момент мы все ещё находимся в потоке HLRHandler
ложим obj и HLRHandler в map
}

Сюда приходят ответы от HLR:
HLRNotificationPool.responseHandler(id) {
ищем по id наш obj и делаем obj.notify
}

svenom_chaos_Ну... Допустим, у нас есть, скажем, HLRHander, который отправляет запрос к HLR и должен ждать. Дальше у нас есть, скажем, HLRNotificationPool, в который HLRHandler ложит себя и id request-а, скажем, так HLRNotificationPool.wait(this, id).

HLRNotificationPool.wait(this, id) {
obj = создаем обьект
obj.wait() - на данный момент мы все ещё находимся в потоке HLRHandler
ложим obj и HLRHandler в map
}

Сюда приходят ответы от HLR:
HLRNotificationPool.responseHandler(id) {
ищем по id наш obj и делаем obj.notify
}
Ну вы сделали ровно то же, что предложил и я. Только вместо CountDownLatch у вас wait/notify. В вашем случае никакой принципиальной разницы, что использовать нет, так как CountDownLatch(1) по своей сути как раз вырождается в wait/notify.

Да, Вы правы. Думаю так и сделаю, только вот ещё посмотрю с Exchanger, может подойдет.

drsmкаков смысл в связи какого-то конкретного потока (worker) с состоянием обработки какого-то конкретного запроса (state)?
я бы сделал мультиплексор, раз уж сплошная асинхронщина.

Смысл есть, по результатам работы каждого потока в БД ложатся данные, пока я не получу ответ от HLR я не могу положить эти данные, потому что результат работы это не только отправка запроса в HLR, а ещё кучу других задач. Частично положить или заниматься post-обработкой я тоже не могу, точнее могу, но на данный момент уже есть кое-какая архитектура и процесс как должно быть, а переделывать сильно, под одну не типичную, для этой задачи, ситуацию - нет желания и возможностей.