|
|
|
Drop HTTP connections
|
|||
|---|---|---|---|
|
#18+
Доброго все времени суток! Есть вопрос. Возможно, кто-то такое уже делал и подскажет оптимальное и лучшее решение. Есть jboss. На нем вертится приложение. Приложение загружает некоторый контент с других серверов: по-разному. И с помощью httpclient и непосредственно вычиткой контента из инпутсрима. Если сервер, с которого данное приложение пытается загрузить контент, отдает данные очень медленно, мы получаем бесконечное "висение" на вычитке данных. В HttpClient, например, даже не существует такого параметра, который бы задавал максимальное время, после которого коннекшин надо рубить. Ну потому что ответ-то он получает 200 ОК и виснет потом уже на вычитке самих данных. Я так понимаю, что тут нужна какая-то прослойка между jboss и сервером, с которого приложение пытается чего-то вычитывать. Какой-то прокси, на котором можно настроить поведение, чтобы он рубил такие коннекшины, которые висят более, например, 30 секунд. Конечно, это можно делать и в ява-коде, добавляя замер времени. Я это испробовал, и оно работает. Но хотелось бы решить эту проблему систематически. Был бы очень благодарен за наводку. Может, кто-то такое уже делал. Спасибо. ______________________________________________________ while(!death){ Life.liveAndBeHappy(); } ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2012, 22:32:24 |
|
||
|
Drop HTTP connections
|
|||
|---|---|---|---|
|
#18+
Большой Синий КитВ HttpClient, например, даже не существует такого параметра, который бы задавал максимальное время, после которого коннекшин надо рубить. setSoTimeout ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2012, 00:10:42 |
|
||
|
Drop HTTP connections
|
|||
|---|---|---|---|
|
#18+
а также: Код: java 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2012, 00:12:14 |
|
||
|
Drop HTTP connections
|
|||
|---|---|---|---|
|
#18+
Kachalov, Это неверно. HttpClient 4.x/** * Defines the socket timeout (<code>SO_TIMEOUT</code>) in milliseconds, * which is the timeout for waiting for data or, put differently, * a maximum period inactivity between two consecutive data packets). * A timeout value of zero is interpreted as an infinite timeout. * <p> * This parameter expects a value of type {@link Integer}. * </p> * @see java.net.SocketOptions#SO_TIMEOUT */ public static final String SO_TIMEOUT = "http.socket.timeout"; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2012, 13:20:36 |
|
||
|
Drop HTTP connections
|
|||
|---|---|---|---|
|
#18+
P.S. Можете смоделирвать ситуацию глубоко "зависания" httpclient с jetty таким образом: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Ну и пытайтесь запросить http://127.0.0.1:1234 с HttpClient 4.x Главное, чтобы в Thread.sleep() стоял период времени < SO_TIMEOUT, который определен для HttpClient. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2012, 13:24:00 |
|
||
|
Drop HTTP connections
|
|||
|---|---|---|---|
|
#18+
Ну тогда свойство "http.connection.timeout". Короче, я хочу сказать что это не проблема для HttpClient, просто надо прошерстить документацию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2012, 13:28:28 |
|
||
|
Drop HTTP connections
|
|||
|---|---|---|---|
|
#18+
KachalovНу тогда свойство "http.connection.timeout". Короче, я хочу сказать что это не проблема для HttpClient, просто надо прошерстить документацию. И это неверно. Я же Вам говорю - нет такого параметра. HttpClient 4.x/** * Determines the timeout in milliseconds until a connection is established. * A timeout value of zero is interpreted as an infinite timeout. * <p> * Please note this parameter can only be applied to connections that * are bound to a particular local address. * <p> * This parameter expects a value of type {@link Integer}. * </p> */ public static final String CONNECTION_TIMEOUT = "http.connection.timeout"; Коннекшин в этом случае всегда получен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2012, 13:31:15 |
|
||
|
Drop HTTP connections
|
|||
|---|---|---|---|
|
#18+
P.S. Зависание идет просто на вычитке данных из респонза. Например, методы EntityUtils.toByteArray и EntityUtls.toString. Там, если посмотреть исходники, нет никакой привязки к периоду времени, в течение которого данные вычитываются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2012, 13:34:05 |
|
||
|
Drop HTTP connections
|
|||
|---|---|---|---|
|
#18+
Ну по ходу, инпустстрим, который используется в EntityUtils закрывается при определенных настройках httpclient. - как для SO_TIMEOUT... Но, к сожалению, параметра для максимального держания коннекшина в httpclient нету ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2012, 13:42:00 |
|
||
|
Drop HTTP connections
|
|||
|---|---|---|---|
|
#18+
Большой Синий КитЕсли сервер, с которого данное приложение пытается загрузить контент, отдает данные очень медленно, мы получаем бесконечное "висение" на вычитке данных. В HttpClient, например, даже не существует такого параметра, который бы задавал максимальное время, после которого коннекшин надо рубить. Большой Синий КитГлавное, чтобы в Thread.sleep() стоял период времени < SO_TIMEOUT, который определен для HttpClient. - что-то я Вас не понимаю :( Для имитации проблемы изложенной в первом посте и проверки работы таймаута, sleep должен быть больше чем значение параметра "http.connection.timeout", иначе невозможно увидеть как отработает принудительный обрыв соединения. Лично у меня настройки ("http.connection.timeout" и "http.socket.timeout") успешно отрабатывали на HttpClient 4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2012, 16:37:05 |
|
||
|
Drop HTTP connections
|
|||
|---|---|---|---|
|
#18+
Kachalov, Извините, Вы просто заблуждаетесь в назначении параметров "http.socket.timeout" и "http.socket.timeout". Я привел полное описание, для чего служит один, и для чего второй. Коннекшин в описанном мной случае получен. Никакого влияние на поведение httpclient параметр "http.connection.timeout" не окажет в данном случае. Может повлиять только "http.socket.timeout" - то есть, если передача данных будет с простоем, который указан для "http.socket.timeout" - httpclient срубит соединение. Потому что: HttpClient/** * Defines the socket timeout (<code>SO_TIMEOUT</code>) in milliseconds, * which is the timeout for waiting for data or, put differently, * a maximum period inactivity between two consecutive data packets ). * A timeout value of zero is interpreted as an infinite timeout. * <p> * This parameter expects a value of type {@link Integer}. * </p> * @see java.net.SocketOptions#SO_TIMEOUT */ public static final String SO_TIMEOUT = "http.socket.timeout"; Поэтому я и указал, что главное, чтобы в Thread.sleep() стоял период времени < SO_TIMEOUT, который определен для HttpClient. Я рад, что у вас стоят эти установки для вашего httpclient. У меня, кстати, тоже. Но они ничем Вам не помогут в случае проблем с низкой скоростью получения данных с урл. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2012, 20:27:11 |
|
||
|
Drop HTTP connections
|
|||
|---|---|---|---|
|
#18+
Большой Синий КитВ HttpClient, например, даже не существует такого параметра, который бы задавал максимальное время, после которого коннекшин надо рубить. Большой Синий КитМожет повлиять только "http.socket.timeout" - то есть, если передача данных будет с простоем, который указан для "http.socket.timeout" - httpclient срубит соединение. - на этом месте прилично было бы сказать "спасибо" Большой Синий КитНо они ничем Вам не помогут в случае проблем с низкой скоростью получения данных с урл. - не делайте из собеседника идиота, получите исключительную ситуацию "java.net.SocketTimeoutException: Read timed out" по таймауту и будет Вам решение проблемы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2012, 21:59:26 |
|
||
|
Drop HTTP connections
|
|||
|---|---|---|---|
|
#18+
Чего-то я не врубаюсь ... посмотрел старый проект. Реальный код: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. setSoTimeout(3000) - не рабочий что ли? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2012, 00:28:24 |
|
||
|
Drop HTTP connections
|
|||
|---|---|---|---|
|
#18+
Kachalov, Послушайте, Вы не вникли в проблему. Я не делаю из Вас идиота, а просто уже несколько раз указывал на то, что Вы не поняли ситуацию. Еще раз объясняю детально. 1. HttpCLient получает соединение. 2. HttpClient пытается загрузить необходимый контент. 3. Сервер, на который подключился HttpClient, отдает данные очень медленно. То есть размер данных мал, но сервер их отдает очень медленно. Ситуация п. 3 смоделирована с помощью описанного выше хендлера для Jetty. Повторяю его код: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Повторяюсь, в данной ситуации Вам ничем не помогут ни http.socket.timeout (с оговоркой, описанной ниже), ни http.connection.timeout . Потому что: а) Соединение уже получено - http.connection.timeout уже не окажет никакого влияния. б) Передача данных идет с задержкой, которая меньше установленного http.socket.timeout . Никакого java.net.SocketTimeoutException в данном случае Вы не получите! P.S. Вместо того, чтобы разобраться в ситуации, Вы придумываете, что я делаю из Вас идиота. Это не так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2012, 10:51:04 |
|
||
|
Drop HTTP connections
|
|||
|---|---|---|---|
|
#18+
IDVsbruckЧего-то я не врубаюсь ... посмотрел старый проект. Реальный код: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. setSoTimeout(3000) - не рабочий что ли? Рабочий. Если коннекшин будет получен, но будет таймаут в передаче данных больше 3 секунд, httpclient разорвет соединение. Но если таймаут будет меньше 3 секунд, то нет. :) Ситуация: Вам нужно загрузить данные размером, к примеру, 2 КБ. Сервер отдает кусок данных, например, 10 байт. Потом зависает на время меньшее 3 секунд, потом снова отдает 10 байт, и снова виснет на малое время... В итоге вы подвиснете на очень долгое время. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2012, 10:54:30 |
|
||
|
Drop HTTP connections
|
|||
|---|---|---|---|
|
#18+
P.S. Именно поэтому я хочу рубить все соединения, которые висят дольше определенного времени. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2012, 11:04:07 |
|
||
|
Drop HTTP connections
|
|||
|---|---|---|---|
|
#18+
Большой Синий Китб) Передача данных идет с задержкой, которая меньше установленного http.socket.timeout . Никакого java.net.SocketTimeoutException в данном случае Вы не получите! - ну так уменьшите задержку в http.socket.timeout ? Если сервер отдает контент быстрее чем Вы установили в качестве допустимого таймаута, то в чем вообще проблема? Радуйтесь что сервер работает быстро и не выносите мозг. Большой Синий КитЕсли сервер, с которого данное приложение пытается загрузить контент, отдает данные очень медленно, мы получаем бесконечное "висение" на вычитке данных. В HttpClient, например, даже не существует такого параметра, который бы задавал максимальное время, после которого коннекшин надо рубить. Ну потому что ответ-то он получает 200 ОК и виснет потом уже на вычитке самих данных. index.jsp (отдает контент за 1 мин) Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. SlowResponseClient.java (готов получить контент, но не дольше чем за 30 сек) Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Результат выполнения клиента: Код: java 1. 2. 3. ЧТО Я ДЕЛАЮ НЕ ТАК? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2012, 11:53:16 |
|
||
|
Drop HTTP connections
|
|||
|---|---|---|---|
|
#18+
Kachalov, Вы не делаете out.flush() ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2012, 12:13:02 |
|
||
|
Drop HTTP connections
|
|||
|---|---|---|---|
|
#18+
Большой Синий Кит, Kachalov- ну так уменьшите задержку в http.socket.timeout? Если сервер отдает контент быстрее чем Вы установили в качестве допустимого таймаута, то в чем вообще проблема? Радуйтесь что сервер работает быстро и не выносите мозг. Проблема в том, чтобы нужно рубить все соединения, которые висят дольше определенного времени. И такого параметра в httpclient НЕТ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2012, 12:16:21 |
|
||
|
Drop HTTP connections
|
|||
|---|---|---|---|
|
#18+
Kachalov, Вы знаете, это начинает надоедать, если честно. Раз за разом все упирается в Вашу невнимательность. Вместо того, чтобы разобраться в проблеме, для эмуляции которой приведен даже исходный код, Вы упорно пишете что попало. Если Вы не хотите разобраться (а это вполне понятно, проблема не Ваша ведь, никто Вас винить не будет), просто не отвечайте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2012, 12:22:12 |
|
||
|
Drop HTTP connections
|
|||
|---|---|---|---|
|
#18+
Большой Синий КитВы знаете, это начинает надоедать, если честно. Раз за разом все упирается в Вашу невнимательность. Вместо того, чтобы разобраться в проблеме, для эмуляции которой приведен даже исходный код, Вы упорно пишете что попало. Если Вы не хотите разобраться (а это вполне понятно, проблема не Ваша ведь, никто Вас винить не будет), просто не отвечайте. - попробуйте просто адекватно сформулировать задачу. Всегда думал что проблема понимания это не только проблема того кто пытается понять, но и того что излагает материал. - задача элементарно решается средствами JavaSE и не требует такого длительного срача в форумах: сервлет StupidResponse.java (отдает результат медленно, в течении 1 мин) Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. клиент в котором котором контролируется время работы ( Scheduled-task pattern ), SlowResponseClient.java: Код: 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. Результат: Код: java 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2012, 12:43:40 |
|
||
|
Drop HTTP connections
|
|||
|---|---|---|---|
|
#18+
Kachalov, В моем первом посте: Конечно, это можно делать и в ява-коде, добавляя замер времени. Я это испробовал, и оно работает. Но хотелось бы решить эту проблему систематически. Спасибо, я это прекрасно понимаю. У меня уже есть такое решение. Оно, безусловно, работает. Но речь идет о том, чтобы не делать так. Нужно одним махом дропать коннекшины, созданные не только с HttpClient, и везде и повсюду внутри приложения. И речь идет о "конфигурационном решении". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2012, 12:55:16 |
|
||
|
Drop HTTP connections
|
|||
|---|---|---|---|
|
#18+
P.S. Если уж на то пошло, то длительный, как Вы выразились, срач развели Вы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2012, 13:02:36 |
|
||
|
Drop HTTP connections
|
|||
|---|---|---|---|
|
#18+
Большой Синий КитКонечно, это можно делать и в ява-коде, добавляя замер времени. Я это испробовал, и оно работает. Но хотелось бы решить эту проблему систематически. - "систематически" - это лирика, либо в рамках приложения, либо в на основе *NIX/Windows архитектуры. Выбирайте. Если программно, то либо sheduled-task, либо, в рамках JavaEE6, то AsyncListener или Future.get с таймаутом (хз что у Вас за приложение, на основе сервлетов, или EJB, или еще что-то). Если на основе инфраструктуры, то это вопрос про настройки proxy. Большой Синий КитНо речь идет о том, чтобы не делать так. - тогда Вы ошиблись топиком, Вам надо в администрирование *NIX/Windows задать вопрос про прокси сервера Большой Синий Кит Нужно одним махом дропать коннекшины, созданные не только с HttpClient, и везде и повсюду внутри приложения. И речь идет о "конфигурационном решении". - имеются в виду проприоетарные настройки JBoss? Большой Синий КитЕсли уж на то пошло, то длительный, как Вы выразились, срач развели Вы. - если можно, комментировать тему моей "невнимательности", и Вашего "это начинает надоедать", не буду. Все таки остаюсь при мнении что фразы типа "коннекшин надо рубить" могут быть истрактованы по разному. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2012, 13:55:41 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=37732672&tid=2132164]: |
0ms |
get settings: |
11ms |
get forum list: |
16ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
47ms |
get topic data: |
14ms |
get forum data: |
4ms |
get page messages: |
83ms |
get tp. blocked users: |
2ms |
| others: | 331ms |
| total: | 518ms |

| 0 / 0 |
