|
|
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
Привет, Вопрос простой и глупый, но не хочется городить свои велосипеды. Задача: есть специальный файл в котором записанны данные по строчкам и для каждой строчки я должен выполнить определённые действия. В данной случае одно из действий это отправка запросов на сервер (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 для этого или как вообще люди делают? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 18:04:35 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
wait/notify тут не место - слишком низкоуровневые концепции. Далете пул потоков, сабмитите в них таски и все. Если надо как-то хитро ждать ответа от HLR (кстати, что это?), то смотрите в сторону высокоуровневых вещей из java.util.concurrent - Barrier, Latch, Semaphore. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 18:08:23 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
svenomто смотрите в сторону высокоуровневых вещей +1. Или даже JMS ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 18:13:46 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
svenom, Дело в том, что потоки уже созданы, то есть я посылаю request к HLR уже в существующем потоке, который должен остановиться и ждать, пока на его запрос не прийдет ответ от сервера. На сколько я знаю эти классы Barrier, Latch, Semaphore, они работаю следующим образом: у нас есть N операций и мы ставим "стену" и "стена" будет сдерживать потоки, пока они все не отработают. В моем же случае, как только notification web-service получил ответ от HLR он должен уведомить ждущий поток о результате и поток должен продолжить работу. HLR содержит данные о SIM-картах оператора мобильной связи ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 18:14:20 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
_chaos_через некоторое время, HLR вызывает мой notification web-service, в который передает данный об успешности/не успешности request В response? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 18:16:02 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
Blazkowiczsvenomто смотрите в сторону высокоуровневых вещей +1. Или даже JMS Слишком мальнькая проблема, что бы для нее городить JMS, нужно что-то попроще... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 18:16:09 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
_chaos_С ходу напрашивается решение: каждый поток, который отправляет request к HLR, добавляет себя в очередь ожидания, после добавления в очередь ожидания, становится в ожидание и ждет ответа от сервера. Ну, вообще клиенты по-умолчанию использую блокирующий IO и каждый поток засыпает, пока не придет ответ. Никаких дополнительных телодвижений для этого не нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 18:17:26 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
Blazkowicz_chaos_через некоторое время, HLR вызывает мой notification web-service, в который передает данный об успешности/не успешности request В response? Именно, там есть id моего request и по нему я могу определить какому потоку отдать результат. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 18:17:31 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
_chaos_На сколько я знаю эти классы Barrier, Latch, Semaphore, они работаю следующим образом: у нас есть N операций и мы ставим "стену" и "стена" будет сдерживать потоки, пока они все не отработаютЭто неверно. Вы описали работу Barrier, Latch и Semaphore это совершенно другие вещи. _chaos_В моем же случае, как только notification web-service получил ответ от HLR он должен уведомить ждущий поток о результате и поток должен продолжить работу.Ну ок, тогда начните с того, что определитесь, как вы будете идентифицировать тот поток, который надо "разбудить". Ну то есть вот у меня стоит в ожидании 10 потоков, вот пришел ответ от HLR. Как вы определяете, какой поток разбудить? Тут отлично впишется класс CountdownLatch. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 18:18:17 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
Blazkowicz_chaos_С ходу напрашивается решение: каждый поток, который отправляет request к HLR, добавляет себя в очередь ожидания, после добавления в очередь ожидания, становится в ожидание и ждет ответа от сервера. Ну, вообще клиенты по-умолчанию использую блокирующий IO и каждый поток засыпает, пока не придет ответ. Никаких дополнительных телодвижений для этого не нужно. В том то и дело, что web-service работает как отправил и забудь (асинхронно). А результат прийдет в notification web-service. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 18:19:10 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
_chaos_Именно, там есть id моего request и по нему я могу определить какому потоку отдать результат.Ну отлично, тогда делаете так. 1. Создаете Runnable, которому передаете некий ваш идентификатор и новый инстанс CountdownLatch: Код: java 1. 2. 2. Далее кладете идентификатор и latch в мапу: latchMap.put(id, latch); 3. В теле вашего Runnable: Код: java 1. 2. 3. 4. 5. 4. При получении ответа от HLR: Код: java 1. 2. 3. Все. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 18:22:54 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
svenom_chaos_На сколько я знаю эти классы Barrier, Latch, Semaphore, они работаю следующим образом: у нас есть N операций и мы ставим "стену" и "стена" будет сдерживать потоки, пока они все не отработаютЭто неверно. Вы описали работу Barrier, Latch и Semaphore это совершенно другие вещи. Насколько я знаю, Barrier и Latch не особо отличаются по семантики, разница лишь в нескольких фичесах, например, в Barrier можно установить barrierAction, который будет вызван когда все потоки будут завершены, а также, например, можно сделать reset count-а. Про Semaphore ничего не могу сказать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 18:27:11 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
авторBarrier и Latch не особо отличаются по семантики, разница лишь в нескольких фичесах, например, в Barrier можно установить barrierAction, который будет вызван когда все потоки будут завершены,Неверно, задачи принципиально разные. Цель барьера - обеспечить одновременный старт нескольких потоков, когда каждый из них придет достигнет определенной точки своего выполнения. Цель латча - обеспечить старт потока(потоков), после того, как другие потоки совершили некие действия. Сементика абсолютно разная. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 18:29:51 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
svenom_chaos_Именно, там есть id моего request и по нему я могу определить какому потоку отдать результат.Ну отлично, тогда делаете так. 1. Создаете Runnable, которому передаете некий ваш идентификатор и новый инстанс CountdownLatch: Код: java 1. 2. 2. Далее кладете идентификатор и latch в мапу: latchMap.put(id, latch); 3. В теле вашего Runnable: Код: java 1. 2. 3. 4. 5. 4. При получении ответа от HLR: Код: java 1. 2. 3. Все. Я не хочу лезть в создание котока, потому что во-первых: он создается в ядре "системы" и не очень то и хотелось навешивать на него ещё какие-то долнительные обьекты, во-вторых: я не знаю о id в то время когда создаю поток. Я вот не пойму, почему если сделать что-то похожее, но организовать всё через обычный монитор, то есть создать object и использовать его notify/wait. Чем это хуже чем дополнительный обьект CountDownLatch? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 18:33:01 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
_chaos_ Я не хочу лезть в создание котока, потому что во-первых: он создается в ядре "системы" и не очень то и хотелось навешивать на него ещё какие-то долнительные обьекты, во-вторых: я не знаю о id в то время когда создаю поток.Так как вы все-таки собираетесь сопоставлять реквесты и респонсы? Ну хотите - создайте внутри потока латч и положите его в какую-нибудь расшаренную мапу. _chaos_ Я вот не пойму, почему если сделать что-то похожее, но организовать всё через обычный монитор, то есть создать object и использовать его notify/wait. Чем это хуже чем дополнительный обьект CountDownLatch? Ок, тогда вот вам вопрос - чего будет ждать поток? Как обычно wait() используется? Вот так: while (condition) { monitor.wait(); } Что у вас будет монитором? Что у вас будет condition? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 18:36:13 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
svenomавторBarrier и Latch не особо отличаются по семантики, разница лишь в нескольких фичесах, например, в Barrier можно установить barrierAction, который будет вызван когда все потоки будут завершены,Неверно, задачи принципиально разные. Цель барьера - обеспечить одновременный старт нескольких потоков, когда каждый из них придет достигнет определенной точки своего выполнения. Цель латча - обеспечить старт потока(потоков), после того, как другие потоки совершили некие действия. Сементика абсолютно разная. Да точно-точно правы, немного подзабыл :). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 18:36:24 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 18:38:17 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
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 } ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 18:48:10 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
_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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 18:54:36 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
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, может подойдет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 18:55:56 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
_chaos_Думаю так и сделаю, только вот ещё посмотрю с Exchanger, может подойдет. Логика та же самая, только проще значние передавать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 18:57:18 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
каков смысл в связи какого-то конкретного потока (worker) с состоянием обработки какого-то конкретного запроса (state)? я бы сделал мультиплексор, раз уж сплошная асинхронщина. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 19:01:34 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
drsmя бы сделал мультиплексор, раз уж сплошная асинхронщина. Ну, хочется человеку stackatrace внятный поиметь, наверное. Других объяснений нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 19:02:48 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
_chaos_, По моему данная задача лучше решается с помощью классического wait/notify Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 19:07:57 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
drsmкаков смысл в связи какого-то конкретного потока (worker) с состоянием обработки какого-то конкретного запроса (state)? я бы сделал мультиплексор, раз уж сплошная асинхронщина. Смысл есть, по результатам работы каждого потока в БД ложатся данные, пока я не получу ответ от HLR я не могу положить эти данные, потому что результат работы это не только отправка запроса в HLR, а ещё кучу других задач. Частично положить или заниматься post-обработкой я тоже не могу, точнее могу, но на данный момент уже есть кое-какая архитектура и процесс как должно быть, а переделывать сильно, под одну не типичную, для этой задачи, ситуацию - нет желания и возможностей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 19:08:30 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
OOsalivanПо моему данная задача лучше решается с помощью классического wait/notify Попробуйте написать через Exchanger - код будет ещё проще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 19:10:25 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
_chaos_drsmкаков смысл в связи какого-то конкретного потока (worker) с состоянием обработки какого-то конкретного запроса (state)? я бы сделал мультиплексор, раз уж сплошная асинхронщина. Смысл есть, по результатам работы каждого потока в БД ложатся данные, пока я не получу ответ от HLR я не могу положить эти данные, потому что результат работы это не только отправка запроса в HLR, а ещё кучу других задач. Частично положить или заниматься post-обработкой я тоже не могу, точнее могу, но на данный момент уже есть кое-какая архитектура и процесс как должно быть, а переделывать сильно, под одну не типичную, для этой задачи, ситуацию - нет желания и возможностей. держишь транзакцию чтоли открытой? это изврат, по хорошему так не делается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 19:18:07 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
drsm_chaos_пропущено... Смысл есть, по результатам работы каждого потока в БД ложатся данные, пока я не получу ответ от HLR я не могу положить эти данные, потому что результат работы это не только отправка запроса в HLR, а ещё кучу других задач. Частично положить или заниматься post-обработкой я тоже не могу, точнее могу, но на данный момент уже есть кое-какая архитектура и процесс как должно быть, а переделывать сильно, под одну не типичную, для этой задачи, ситуацию - нет желания и возможностей. держишь транзакцию чтоли открытой? это изврат, по хорошему так не делается. не в транзации дело, я не использую их на протяжении всей работы потока, потому что я не смогу сделать откат, скажем, из какой-то внешней системы (например из SMSC или MMSC или VMS), потому что она не поддерживает транзакции. Суть больше в том, что был один заказчик и для него писалось, а потом появился другой-третий и я не могу тратить время на переписывание каких-то больших частей, моя задача быстро адаптировать и дописать то, что нужно, но не переписывать, потому что сроки ограничены. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 19:33:40 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
OOsalivan_chaos_, По моему данная задача лучше решается с помощью классического wait/notify Код: 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. Эээ, а что делает метод getThredID()? Как он работает? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 20:10:56 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
svenomOOsalivan_chaos_, По моему данная задача лучше решается с помощью классического wait/notify Код: 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. Эээ, а что делает метод getThredID()? Как он работает? :) _chaos_Дальше у меня есть веб-сервис, в который будут приходить responses от HLR и мне нужно уведомлять потоки, которые ждут ответы от HLR о результате. Метод public void webServiceRequestListener() - это (конечно в ООП лучше его сделать не методом а интерфайсом с реализацией, но лень писать) как раз слушатель responses от HLR, а в респонсах содержится соответственно идентификатор того потока кому он предназначается и метод getThreadID() извлекает этот идентификатор из респонса. Т.е когда приходит респонс от HLR дергается webServiceRequestListener с информацией которая пришла в респонсе. public void webServiceRequestListener(Responce resp) -> getThreadID(Responce resp) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 22:23:05 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
А понятно, тогда это точно такое же решение, как я предложил выше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2012, 22:48:21 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
BlazkowiczOOsalivanПо моему данная задача лучше решается с помощью классического wait/notify Попробуйте написать через Exchanger - код будет ещё проще. Так и сделал. Кстати, я считаю, что лучше, в данном случае, использовать все-таки concurrent классы, так как они используют CAS, вместо стандартного механизма. Ещё один + в сторону Exchanger. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2012, 12:09:03 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
_chaos_Blazkowiczпропущено... Попробуйте написать через Exchanger - код будет ещё проще. Так и сделал. Кстати, я считаю, что лучше, в данном случае, использовать все-таки concurrent классы, так как они используют CAS, вместо стандартного механизма. Ещё один + в сторону Exchanger. В том что я написал тоже частично КАС используется. Интересно было бы взглянуть на реализацию через эксченджер ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2012, 12:54:30 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
OOsalivan_chaos_пропущено... Так и сделал. Кстати, я считаю, что лучше, в данном случае, использовать все-таки concurrent классы, так как они используют CAS, вместо стандартного механизма. Ещё один + в сторону Exchanger. В том что я написал тоже частично КАС используется. Интересно было бы взглянуть на реализацию через эксченджер Это пока набросок, я ещё не знаю всех данных. HLRHandler - класс, который отправляет запрос в HLR и ожидает ответ. Код: 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. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. NotificationServiceImpl - класс, который принимает ответы от HLR и уведомляет о результате Код: 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. 47. 48. 49. Я пока жду некоторые данные и после этого начну тестировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2012, 14:05:04 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
_chaos_Blazkowiczпропущено... Попробуйте написать через Exchanger - код будет ещё проще. Так и сделал. Кстати, я считаю, что лучше, в данном случае, использовать все-таки concurrent классы, так как они используют CAS, вместо стандартного механизма. Ещё один + в сторону Exchanger. Еще в данном случае алгоритмы КАС и блокировка не взаимоисключающие вещи, потому что поток нужно блокировать . В том что я написал выше, блокировка используется только там где без нее не обойтись исходя из самих условий задачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2012, 14:28:54 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
OOsalivan, Да, я что-то то же не вдуплил, нафига тут CAS нужен и в чем заключается его реимущество ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2012, 14:34:07 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
_chaos_, По моему в вашей реализации а эксченджером напутано, непонятно где тормозиться поток. Вообще эксченджеры сущетвуют для передачи объекта между потоками ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2012, 22:41:18 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
Вообще не понятно зачем тут эксченджер, если никакого эксчанджа нет и в помине. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2012, 23:33:18 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2012, 00:18:53 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
OOsalivan_chaos_, По моему в вашей реализации а эксченджером напутано, непонятно где тормозиться поток. Вообще эксченджеры сущетвуют для передачи объекта между потоками Тормрзится-то он затормозится, а вот сможет ли он потом очнуться? Что-то сомневаюсь Если придут два запроса с одинаковым ticket-ом и если на момент прибытия второго, первый обработается, то поток, ожидающий первого должен таки повиснуть навсегда (т.к. кладется один эксченджер, а достаем другой). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2012, 00:31:06 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
schwa, Суть задачи проста как я понял - запустить поток, в нем выполнить реквест к вебсервису и остановить поток (после реквета есть еще ряд действий, но которые нужно выполнить послле респонса). В отдельном потоке приходят респонсы от вебсервиса которые возобновляют ранее приостановленные потоки. getOnWithIt - что делает метод? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2012, 17:19:51 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
Это метод вебсервиса автора, очищенный от информационного мусора. Получаем запрос -> обрабатываем(блокируя текущий поток) -> получаем результат (разблокировав текущий поток) -> возвращаем как ответ вебсервиса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2012, 18:20:03 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
schwaЭто метод вебсервиса автора, очищенный от информационного мусора. Получаем запрос -> обрабатываем(блокируя текущий поток) -> получаем результат (разблокировав текущий поток) -> возвращаем как ответ вебсервиса. Создаем поток который выполняет некотрый код, сперва этот код делает запрос к вебсервису (после чего поток должен быть заблокирован). И каким образом в вебсервисе мы сможем заблокировать поток из которого ушел ответ на вебсервис (подразумеваеться что вебсервис колл асинхронный - вызвали и поехал идальше не дожидаясь ответа)?? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2012, 22:10:30 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
OOsalivan_chaos_, По моему в вашей реализации а эксченджером напутано, непонятно где тормозиться поток. Вообще эксченджеры сущетвуют для передачи объекта между потоками Почему ж напутно? В NotificationServiceImpl я передаю exchanger, ticket, и пустой HLRResponse (мне не нужно что б он был заполнен для NotificationServiceImpl) и поток ждет ответ от NotificationServiceImpl. Из NotificationServiceImpl в HLRHandler я передаю заполненый HLRResponse и всё, поток продолжает свою работу. З.Ы. Два одинаковых ticket-а быть не может - я контролирую уникальность тикитов. З.Ы. З.Ы. Если в HLRHandler не приходит ответ в течении HLR_TIMEOUT, то срабатывает exception и запрос считается failed. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2012, 12:42:05 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
_chaos_OOsalivan_chaos_, По моему в вашей реализации а эксченджером напутано, непонятно где тормозиться поток. Вообще эксченджеры сущетвуют для передачи объекта между потоками Почему ж напутно? В NotificationServiceImpl я передаю exchanger, ticket, и пустой HLRResponse (мне не нужно что б он был заполнен для NotificationServiceImpl) и поток ждет ответ от NotificationServiceImpl. Из NotificationServiceImpl в HLRHandler я передаю заполненый HLRResponse и всё, поток продолжает свою работу. З.Ы. Два одинаковых ticket-а быть не может - я контролирую уникальность тикитов. З.Ы. З.Ы. Если в HLRHandler не приходит ответ в течении HLR_TIMEOUT, то срабатывает exception и запрос считается failed. Зачем так усложнять? У вас получается батлнек в методе Код: java 1. . Представьте у вас будет 10000 потоков и от вебсервиса будет 10000 респонсов, в вашей реализации итератор будет пробегать в худшем случае 1000 раз, как все будет подтормаживать (т.е сложность алгоритма O(n)), а в том что я писал выше сложность - O(1) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2012, 16:54:59 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
OOsalivan, Вы однозначно правы - я затупил (реализация быстро, на коленках это на самом деле), можно из хеш-таблицы получать значение и не использовать итератор - это очевидно. А в целом, ничего не поменяется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2012, 18:00:35 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
_chaos_OOsalivan, Вы однозначно правы - я затупил (реализация быстро, на коленках это на самом деле), можно из хеш-таблицы получать значение и не использовать итератор - это очевидно. А в целом, ничего не поменяется. Еще каждый раз создание нового объекта Exchanger на очередной поток + не явное его использование(не для передачи объекта между потоками). Если важна производительность то для нотификации быстрее сработает нативный метод обжекта notifyAll, чем выборка из хэш таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2012, 18:15:37 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
OOsalivanЕсли важна производительность то для нотификации быстрее сработает нативный метод обжекта notifyAll, чем выборка из хэш таблицыДаа фигня это, никто не заметит разницу в несколько микросекунд с выборкой из HashMap и без оной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2012, 18:21:14 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
BlazkowiczOOsalivanПо моему данная задача лучше решается с помощью классического wait/notify Попробуйте написать через Exchanger - код будет ещё проще. 90% синхронизационных задач решается с помощью очередей сообщений. wait/notify, latch, barrier, semafore - это все низкоуровневые средства, и нужны, как правило, лишь для реализации нестандартных очередей. Exchanger - это нестандартная очередь (двунаправленная, с нулевым объемом буфера). Недостаток ее использования в данной задаче - если инициирующий поток задержится с выполнением запроса для получения respons'a - будет задержан нотифицирующий поток. Смысла же его задерживать нет. Поэтому объем буфера должен быть как минимум 1. Самый подходящий вариант - new ArrayBlockingQueue(1). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2012, 19:47:02 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
rfqесли инициирующий поток задержится с выполнением запроса для получения respons'a - будет задержан нотифицирующий поток. Смысла же его задерживать нет. Поэтому объем буфера должен быть как минимум 1. Самый подходящий вариант - new ArrayBlockingQueue(1). Рассуждения логичные, но в данном случае притянуты за уши. Т.е. нотификация с удаленного сервера может прийти раньше чем инициирующий поток уснет после отправки данных? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2012, 10:14:13 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
Blazkowicz Т.е. нотификация с удаленного сервера может прийти раньше чем инициирующий поток уснет после отправки данных?Может - ни один планировщик потоков не может вам гарантировать, что между соседними предложениями (отправка запроса и ожидание нотификации) не будет заметной паузы, хотя, конечно, вероятность этого мала. А еще в эту щель программисты-сопровождающие потом могут вставить какую-нибудь работу. Короче, не надо увеличивать число предпосылок для нормального функционирования. Обходиться минимумом - этот признак хорошего стиля проектирования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2012, 15:02:33 |
|
||
|
Какие API классы или pattern-ы лучше использовать?
|
|||
|---|---|---|---|
|
#18+
rfqМожет - ни один планировщик потоков не может вам гарантировать, что между соседними предложениями (отправка запроса и ожидание нотификации) не будет заметной паузы, хотя, конечно, вероятность этого мала. А еще в эту щель программисты-сопровождающие потом могут вставить какую-нибудь работу. Короче, не надо увеличивать число предпосылок для нормального функционирования. Обходиться минимумом - этот признак хорошего стиля проектирования. Вы правы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2012, 16:44:28 |
|
||
|
|

start [/forum/topic.php?all=1&fid=59&tid=2132685]: |
0ms |
get settings: |
15ms |
get forum list: |
26ms |
check forum access: |
7ms |
check topic access: |
7ms |
track hit: |
56ms |
get topic data: |
17ms |
get forum data: |
5ms |
get page messages: |
113ms |
get tp. blocked users: |
2ms |
| others: | 380ms |
| total: | 628ms |

| 0 / 0 |
