|
|
|
Какие 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 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=37633804&tid=2132685]: |
0ms |
get settings: |
14ms |
get forum list: |
24ms |
check forum access: |
8ms |
check topic access: |
8ms |
track hit: |
51ms |
get topic data: |
16ms |
get forum data: |
4ms |
get page messages: |
90ms |
get tp. blocked users: |
2ms |
| others: | 339ms |
| total: | 556ms |

| 0 / 0 |
