Внедрение HttpURLConnection

Question

Я читал, что HttpURLConnection поддерживает постоянные подключения, так что соединение может быть повторно использовано для нескольких запросов. Я попробовал это, и единственный способ отправить второй POST - это вызов openConnection во второй раз. В противном случае я получил исключение IllegalStateException («Уже подключено»); я использовал следующее:

try{ 
URL url = new URL("http://someconection.com"); 
} 
catch(Exception e){} 
HttpURLConnection con = (HttpURLConnection) url.openConnection(); 
//set output, input etc 
//send POST 
//Receive response 
//Read whole response 
//close input stream 
con.disconnect();//have also tested commenting this out 
con = (HttpURLConnection) url.openConnection(); 
//Send new POST 

Второй запрос отправить через соединение TCP же (проверить его с помощью Wireshark), но я не могу понять, почему (хотя это то, что я хочу), так как я назвал разъединение. Я проверил исходный код для HttpURLConnection, и реализация сохраняет хранимый кэш подключений к тем же адресам. Моя проблема в том, что я не вижу, как соединение помещается обратно в кеш после того, как я пришлю первый запрос. Отключение закрывает соединение и без разъединения, но я не вижу, как соединение помещается обратно в кеш. Я видел, что в кеше есть метод запуска для прохождения через все незанятые соединения (я не уверен, как это называется), но я не могу найти, как соединение помещается обратно в кеш. Единственное место, которое, похоже, происходит в готовом методе httpClient, но это не вызвано POST с ответом. Может ли кто-нибудь помочь мне в этом?

EDIT Мой интерес, что надлежащее обращение объекта HttpURLConnection для повторного использования соединения TCP. Если поток ввода/вывода должен быть закрыт, а затем url.openConnection(); каждый раз, чтобы отправить новый запрос (избегая отключения())? Если да, я не вижу, как соединение повторно используется, когда я вызываю url.openConnection() во второй раз, поскольку соединение было удалено из кеша для первого запроса и не может найти способ его возврата. Возможно ли, что соединение не возвращается обратно в кэш-память keepalive (ошибка?), Но ОС еще не выпустила соединение tcp и при новом соединении, ОС возвращает буферное соединение (еще не выпущенное) или что-то подобное? EDIT2 только родственный я нашел был из JDK_KeepAlive

... когда приложение вызывает близко() на InputStream, возвращаемый URLConnection.getInputStream(), обработчик протокола HTTP JDK будет пытаться , чтобы очистить соединение, и если успешно, установите соединение в кеш-соединение для повторного использования в будущем HTTP-запросы.

Но я не уверен, какой обработчик это. sun.net.www.protocol.http.Handler не делает никакого кэширования, как я видел Спасибо!

Answer 1

Если входной выходной поток/закрыто с последующим url.openConnection(); каждый раз, чтобы отправить новый запрос (избегая отключения())?

Да.

Если да, то я не могу видеть, как соединение быть повторно, когда я называю url.openConnection() для второго времени, так как соединение было удаляется из кэша для первого запроса и не может найти, как это вернулся.

Вы путаете HttpURLConnection с подстилающей Socket и его ТСР-соединение. Они не то же самое. Экземпляры HttpURLConnection являются GC'd, базовые Socket объединяются, если вы не позвоните disconnect().

Answer 2

Из Javadoc для HttpURLConnection (курсив мой):

Каждый экземпляр HttpURLConnection является используется для изготовления одного запроса, но лежащий в основе сетевого соединения с сервером HTTP в может быть прозрачно совместно с другими экземпляров. Вызов методов Close() на InputStream или OutputStream из HttpURLConnection с после запроса может бесплатной сетью ресурсы, связанные с этим , например, но не оказывает никакого влияния на любом совместно постоянное соединение.Вызов метод disconnect() может закрыть базовый разъем , если постоянное соединение в противном случае простаивает при этом времени.

Answer 3

Я обнаружил, что соединение действительно кэшируется, когда InputStream закрыт. Как только входной поток был закрыт, базовое соединение буферизуется. Объект HttpURLConnection непригоден для дополнительных запросов, хотя, поскольку объект считается еще «подключенным», то есть его логическое соединение установлено в true и не очищается после того, как соединение помещено обратно в буфер. Поэтому каждый раз, когда новый HttpUrlConnection должен быть создан для нового POST, но базовое TCP-соединение будет использоваться повторно, если оно не было отключено. Итак, ответ EJP был правильным описанием. Может быть, поведение, которое я видел, (повторное использование TCP-соединения), несмотря на явно вызывающий disconnect(), было связано с кэшированием, выполняемым ОС? Я не знаю. Надеюсь, кто-то, кто знает, может объяснить. Спасибо.

Answer 4

Хм. Я могу быть что-то отсутствую здесь (так как это старый вопрос), но, насколько я знаю, есть 2 хорошо известные способы заставить закрытие базового соединения TCP: использование

• силы HTTP 1.0 (1.1 введенные постоянные соединения) - это, как указано в строке запроса HTTP
• Отправлять заголовок «Соединение» со значением «закрыть»; это также закроет закрытие.

Answer 5

Как вы "сила использование HTTP1.0" с использованием HttpURLConnection в JDK?

По поддержке секции „Persistent Connections” of the Java 1.5 guide для HTTP1.1 соединений может быть включен или выключен с помощью свойства Java http.keepAlive (по умолчанию это правда). Кроме того, свойство java http.maxConnections указывает максимальное количество (одновременных) соединений для каждого пункта назначения, которое будет поддерживаться в любой момент времени.

Следовательно, для всего приложения сразу можно применить «принудительное использование HTTP1.0», установив для свойства java http.keepAlive значение false.

Answer 6

Отказ от потоков приведет к простоям TCP-соединений. Поток ответа должен быть прочитан полностью. Еще одна вещь, которую я забыл изначально, и в большинстве ответов на эту тему упускал из виду, забывает иметь дело с потоком ошибок в случае исключений. Код похож на этот фиксированный один из моих приложений, которые не высвобождая ресурсы должным образом:

HttpURLConnection connection = (HttpURLConnection)new URL(uri).openConnection(); 
InputStream stream = null; 
BufferedReader reader = null; 
try { 
     stream = connection.getInputStream(); 
     reader = new BufferedReader(new InputStreamReader(stream, Charset.forName("UTF-8"))); 

     // do work on part of the input stream 

} catch (IOException e) { 

    // read the error stream 
    InputStream es = connection.getErrorStream(); 
    if (es != null) { 
     BufferedReader esReader = null; 
     esReader = new BufferedReader(new InputStreamReader(es, Charset.forName("UTF-8"))); 
     while (esReader.ready() && esReader.readLine() != null) { 
     } 
     if (esReader != null) 
      esReader.close(); 
    } 

    // do something with the IOException 
} finally { 

    // finish reading the input stream if it was not read completely in the try block, then close 
    if (reader != null) { 
     while (reader.readLine() != null) { 
     } 
     reader.close(); 
    } 

    // Not sure if this is necessary, closing the buffered reader may close the input stream? 
    if (stream != null) { 
     stream.close(); 
    } 

    // disconnect 
    if (connection != null) { 
     connection.disconnect(); 
    } 
} 

Буферизованные читатель не является строго необходимым, я выбрал его, потому что мой случай использования требуется чтение одной строки за один раз.

Смотрите также: http://docs.oracle.com/javase/1.5.0/docs/guide/net/http-keepalive.html