Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Message-ID: <1574639254.1260317238582.JavaMail.jira@brutus>
Date: Wed, 9 Dec 2009 00:07:18 +0000 (UTC)
From: "Glyn Davies (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Subject: [jira] Commented: (HTTPCLIENT-875) DefaultClientConnectionOperator
 doesn't update socket after call to connectSocket(...)
In-Reply-To: <1566897726.1252504257548.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HTTPCLIENT-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787818#action_12787818 ] 

Glyn Davies commented on HTTPCLIENT-875:
----------------------------------------


I'm looking at MultihomePlainSocketFactory which creates a new client socket object under exception situations.

This new socket is returned, and replaces the initial socket that was created.

This would be fine if the update() replaced the existing socket straight away, but this fails because the initial socket is not open.


> DefaultClientConnectionOperator doesn't update socket after call to connectSocket(...)
> --------------------------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-875
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-875
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient
>    Affects Versions: 4.0 Beta 2, 4.0 Final
>            Reporter: Connell Gauld
>             Fix For: 4.1 Alpha1
>
>         Attachments: HTTPCLIENT-875-2.patch, HTTPCLIENT-875.diff
>
>
> In the DefaultClientConnectionOperator function openConnection(...) it calls SocketFactory.connectSocket(...). The documentation for connectSocket(...) says that it returns:
>    "the connected socket. The returned object may be different from
> the sock argument if this factory supports a layered protocol. "
> A quick peek at the source showed:
> In org.apache.http.impl.conn.DefaultClientConnectionOperator:
> 117         final SocketFactory sf = schm.getSocketFactory();
> 118
> 119         Socket sock = sf.createSocket();
> 120         conn.opening(sock, target);
> 121
> 122         try {
> 123             sock = sf.connectSocket(sock, target.getHostName(),
> 124                     schm.resolvePort(target.getPort()),
> 125                     local, 0, params);
> 126         } catch (ConnectException ex) {
> 127             throw new HttpHostConnectException(target, ex);
> 128         }
> 129         prepareSocket(sock, context, params);
> 130         conn.openCompleted(sf.isSecure(sock), params);
> So DefaultClientConnectionOperator never updates conn with the new version of sock that may have been returned from connectSocket(...).
> adding:
>         130         conn.openCompleted(sf.isSecure(sock), params);
> +++ 131         conn.update(sock, target, sf.isSecure(sock), params);
> appears to fix the issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org