|
|
|
Client Connection Pool
|
|||
|---|---|---|---|
|
#18+
Доброго времени суток! Задача следующая. Есть JAX WS сервис, который через пул соединений делает запрос на сторонний TCP сервер. Каждое соединение в пуле работает в отдельном потоке, соответственно ответ от TCP сервера обрабатывается в run(). Логика следующая, при обращению в сервис создается пакет, который отправляется в свободное на данный момент соединение в пуле, затем получает ответ от TCP сервера, возвращает соединение в пул и отдает ответ в сервис. Вопрос в следующим, каким образом правильнее всего дождаться ответ TCP сервера и передать этот ответ в метод сервиса, откуда запрос был инициирован, поскольку ответ от TCP сервера может придти с задержкой. Спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2015, 17:09 |
|
||
|
Client Connection Pool
|
|||
|---|---|---|---|
|
#18+
Самым правильным вариантом был бы Continuation, но, как на зло, его нет в Java. Но есть java.util.concurrent.Future - ссылка на будущий результат. Всё зависит от архитектуры кода, который этот пул использует. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2015, 17:19 |
|
||
|
Client Connection Pool
|
|||
|---|---|---|---|
|
#18+
micoloss, вообще без пула - долгое соединение? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2015, 17:22 |
|
||
|
Client Connection Pool
|
|||
|---|---|---|---|
|
#18+
Предполагается большое количество запросов к сервису, поэтому и решено использовать пул, чтобы сэкономить время на подключение к TCP серверу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2015, 17:25 |
|
||
|
Client Connection Pool
|
|||
|---|---|---|---|
|
#18+
micolossПредполагается большое количество запросов к сервису, поэтому и решено использовать пул, чтобы сэкономить время на подключение к TCP серверу а кто источник запросов? Есть понятие сессия. Без всякого пула. 100 клиентов, в начале работы - создале 100 коннектов. И пускай хоть миллион запросов отправляют. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2015, 17:35 |
|
||
|
Client Connection Pool
|
|||
|---|---|---|---|
|
#18+
Petro123, Мне не нужно чтоб к TCP серверу было 100 коннектов, должно быть ограниченное количество и чтобы эти коннекты использовались по мере необходимости. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2015, 17:42 |
|
||
|
Client Connection Pool
|
|||
|---|---|---|---|
|
#18+
micolossМне не нужно очень обоснованно. Тем более, что асинхронность не нужна - нужно ждать ответа сервера. Удачи! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2015, 17:46 |
|
||
|
Client Connection Pool
|
|||
|---|---|---|---|
|
#18+
Petro123, SOAP не поддерживает сессионность, каждое обращение уникальное ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2015, 17:51 |
|
||
|
Client Connection Pool
|
|||
|---|---|---|---|
|
#18+
Как вариант пул потоков, ограниченный числом. Создаём таск, отдаём пулу на обработку, и ждём на Future когда таска закончится. Profit. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2015, 17:59 |
|
||
|
Client Connection Pool
|
|||
|---|---|---|---|
|
#18+
micolossДоброго времени суток! Задача следующая. Есть JAX WS сервис, который через пул соединений делает запрос на сторонний TCP сервер. Каждое соединение в пуле работает в отдельном потоке, соответственно ответ от TCP сервера обрабатывается в run(). Логика следующая, при обращению в сервис создается пакет, который отправляется в свободное на данный момент соединение в пуле, затем получает ответ от TCP сервера, возвращает соединение в пул и отдает ответ в сервис. Вопрос в следующим, каким образом правильнее всего дождаться ответ TCP сервера и передать этот ответ в метод сервиса, откуда запрос был инициирован, поскольку ответ от TCP сервера может придти с задержкой. Спасибо!Клиент JAX-WS поддерживает пулирование исполнения. Возможно хватит. Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2015, 20:58 |
|
||
|
Client Connection Pool
|
|||
|---|---|---|---|
|
#18+
Прошу прощения, поторопился. Executor здесь не для пула... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2015, 21:30 |
|
||
|
Client Connection Pool
|
|||
|---|---|---|---|
|
#18+
DDiverКак вариант пул потоков, ограниченный числом. Создаём таск, отдаём пулу на обработку, и ждём на Future когда таска закончится. Profit. Хорошо, допустим как дождаться ответа от таска понятно. Не понятно каким образом отправя сообщение TCP серверу через сокет, который уже подконнекчен и находится в пуле соединений и работает в отдельном потоке, дождаться ответа от TCP сервера и вернуть этот ответ в таск. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2015, 11:34 |
|
||
|
Client Connection Pool
|
|||
|---|---|---|---|
|
#18+
micoloss, зачем вам вообще пул tcp соединений? Клиенты же ходят по HTTP ? В общей массе времени, время на создание соединения, я думаю будет почти не заметно. Или же вы уже делали тесты и они показали что что основные потери на создании соединений? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2015, 11:50 |
|
||
|
Client Connection Pool
|
|||
|---|---|---|---|
|
#18+
micolossХорошо, допустим как дождаться ответа от таска понятно. Не понятно каким образом отправя сообщение TCP серверу через сокет, который уже подконнекчен и находится в пуле соединений и работает в отдельном потоке, дождаться ответа от TCP сервера и вернуть этот ответ в таск. Future.get() блокирует поток пока не появится результат. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2015, 12:25 |
|
||
|
Client Connection Pool
|
|||
|---|---|---|---|
|
#18+
DDiverзачем вам вообще пул tcp соединений? Клиенты же ходят по HTTP ? В общей массе времени, время на создание соединения, я думаю будет почти не заметно. Или же вы уже делали тесты и они показали что что основные потери на создании соединений? Поддерживаю. Отправка запроса, обработка и получение ответа займут намного больше времени чем пересоздание соединения. Поэтому процентный выигрыш от пере-использования TCP соединения видится сомнительным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2015, 12:27 |
|
||
|
Client Connection Pool
|
|||
|---|---|---|---|
|
#18+
согласен с двумя предыдущими ораторами, правда в практике был случай когда сервер постоянно досили, он был под https, и если уж соединение установлено, его было чертвоски обидно терять ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2015, 12:56 |
|
||
|
Client Connection Pool
|
|||
|---|---|---|---|
|
#18+
micolossPetro123, SOAP не поддерживает сессионность, каждое обращение уникальное Фраза требует уточнения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2015, 13:22 |
|
||
|
Client Connection Pool
|
|||
|---|---|---|---|
|
#18+
BlazkowiczDDiverзачем вам вообще пул tcp соединений? Клиенты же ходят по HTTP ? В общей массе времени, время на создание соединения, я думаю будет почти не заметно. Или же вы уже делали тесты и они показали что что основные потери на создании соединений? Поддерживаю. Отправка запроса, обработка и получение ответа займут намного больше времени чем пересоздание соединения. Поэтому процентный выигрыш от пере-использования TCP соединения видится сомнительным. Скажем так, у TCP сервера к которому идут запросы от сервиса, есть некая процедура регистрации соединения в своей системе которая занимает определённое количество времени, поэтому на каждый пользовательский запрос от веб сервиса создавать новое соединение - не мой случай. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2015, 14:35 |
|
||
|
Client Connection Pool
|
|||
|---|---|---|---|
|
#18+
micolossСкажем так, у TCP сервера к которому идут запросы от сервиса, есть некая процедура регистрации соединения в своей системе которая занимает определённое количество времени, поэтому на каждый пользовательский запрос от веб сервиса создавать новое соединение - не мой случай. Ну, тогда вопрос же решен? Нет? Что не так с Future? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2015, 15:16 |
|
||
|
Client Connection Pool
|
|||
|---|---|---|---|
|
#18+
Blazkowicz, Если я правильно Вас понял, должно быть что-то типа такого: Код: 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. Как дождаться ответа от сервера, после выполнения c.send, делать while(true) и ждать пока допустим что-то типа c.ResponsePaketReady() не вернет true и завершить цикл, или как-то по другому ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2015, 16:46 |
|
||
|
Client Connection Pool
|
|||
|---|---|---|---|
|
#18+
micolossКак дождаться ответа от сервера, после выполнения c.send, делать while(true) и ждать пока допустим что-то типа c.ResponsePaketReady() не вернет true и завершить цикл, или как-то по другому ? Не врубаюсь о каком именно API речь? Возьмите любой блокирующий. Даже NIO может работать в блокирующем режиме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2015, 18:33 |
|
||
|
Client Connection Pool
|
|||
|---|---|---|---|
|
#18+
Мой вопрос повис в воздухе. У SOAP нет сеанса. Забавненько. Но если-бы мы говорили о Restful то не было-бы вообще никакого сеанса тоже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2015, 19:03 |
|
||
|
Client Connection Pool
|
|||
|---|---|---|---|
|
#18+
mayton, А что SOAP поддерживает сессионность? У него есть keep-alive или что-то в этом роде? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2015, 19:11 |
|
||
|
Client Connection Pool
|
|||
|---|---|---|---|
|
#18+
micolossА что SOAP поддерживает сессионность? У него есть keep-alive или что-то в этом роде? Вы прыгаете с одного на другое. Начинаете тему про TCP, затем почему-то подключаете SOAP. Это же разные уровни модели OSI. По-моему здесь вообще не нужны никакие потоки, Future и прочия. Нужен один единственный блокирующий пул сокетов. Который через SocketFactory надо скормить вашему JAX-WS клиенту. Всё. Все вызовы блокирующие и клиентские потоки будут ждать результатов или высвобождения сокетов в пуле. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2015, 19:34 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=38891025&tid=2125750]: |
0ms |
get settings: |
9ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
165ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
84ms |
get tp. blocked users: |
1ms |
| others: | 242ms |
| total: | 538ms |

| 0 / 0 |
