0

アプリケーションでを使用しようとしたときに、ややこしい難問に遭遇しましたHttpClient。一見ランダムに、HttpClient.execute(HttpRequest)二度と戻らない！まあ...それを使用してタイムアウトを設定するHttpConnectionParams.setConnectionTimeout(HttpParams, int)と、タイムアウト例外がスローされます。そうしないと、バックグラウンド スレッドが永久にハングします。

この問題を解決するために太陽の下であらゆることを試みましたが、役に立ちませんでした。代替手段がないまま、問題のパケットキャプチャを行ったところ、驚くべきことがわかりました! （または、それほど驚くべきことではないかもしれませんが、私は実際にはネットワークの男ではありません）

成功した呼び出し:

 905 75.286537   192.168.20.163        192.168.20.171        TCP      74     34340 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=411399 TSecr=0 WS=16
 906 75.286634   192.168.20.171        192.168.20.163        TCP      74     http > 34340 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1260 WS=256 SACK_PERM=1 TSval=2129684 TSecr=411399
 919 78.280782   192.168.20.163        192.168.20.171        TCP      74     34340 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=411783 TSecr=0 WS=16
 920 78.286704   192.168.20.171        192.168.20.163        TCP      74     http > 34340 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1260 WS=256 SACK_PERM=1 TSval=2129984 TSecr=411399
 955 84.280710   192.168.20.163        192.168.20.171        TCP      74     34340 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=412551 TSecr=0 WS=16
 956 84.287958   192.168.20.171        192.168.20.163        TCP      70     http > 34340 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1260 SACK_PERM=1 TSval=2130584 TSecr=411399
 957 84.288332   192.168.20.163        192.168.20.171        TCP      66     34340 > http [ACK] Seq=1 Ack=1 Win=93440 Len=0 TSval=412551 TSecr=2130584
 959 84.648812   192.168.20.163        192.168.20.171        TCP      294    [TCP segment of a reassembled PDU]
 960 84.649333   192.168.20.163        192.168.20.171        HTTP     411    POST /xxxxx.Service/xxxxx.asmx/GetReservations HTTP/1.1  (application/json)
 961 84.649368   192.168.20.171        192.168.20.163        TCP      66     http > 34340 [ACK] Seq=1 Ack=574 Win=16630272 Len=0 TSval=2130620 TSecr=412598
 962 84.656518   192.168.20.171        192.168.20.163        TCP      1314   [TCP segment of a reassembled PDU]
 963 84.656560   192.168.20.171        192.168.20.163        HTTP     580    HTTP/1.1 200 OK  (application/json)
 964 84.657192   192.168.20.163        192.168.20.171        TCP      66     34340 > http [ACK] Seq=574 Ack=1249 Win=119808 Len=0 TSval=412599 TSecr=2130621
 965 84.686906   192.168.20.163        192.168.20.171        TCP      66     34340 > http [ACK] Seq=574 Ack=1764 Win=159744 Len=0 TSval=412603 TSecr=2130621
 968 85.187509   192.168.20.163        192.168.20.171        TCP      66     34340 > http [FIN, ACK] Seq=574 Ack=1764 Win=159744 Len=0 TSval=412667 TSecr=2130621
 969 85.187567   192.168.20.171        192.168.20.163        TCP      66     http > 34340 [ACK] Seq=1764 Ack=575 Win=16630272 Len=0 TSval=2130674 TSecr=412667

呼び出しに失敗しました:

2653 195.296440  192.168.20.163        192.168.20.171        TCP      74     60962 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=426761 TSecr=0 WS=16
2656 195.296894  192.168.20.171        192.168.20.163        TCP      74     http > 60962 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1260 WS=256 SACK_PERM=1 TSval=2141685 TSecr=426761
2658 195.297191  192.168.20.163        192.168.20.171        TCP      66     60962 > http [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSval=426761 TSecr=2141685
2659 195.669276  192.168.20.163        192.168.20.171        TCP      294    [TCP segment of a reassembled PDU]
2660 195.669749  192.168.20.163        192.168.20.171        HTTP     411    POST /xxxxx.Service/xxxxx.asmx/GetReservations HTTP/1.1  (application/json)
2661 195.669783  192.168.20.171        192.168.20.163        TCP      66     http > 60962 [ACK] Seq=1 Ack=574 Win=66048 Len=0 TSval=2141722 TSecr=426809
2662 195.670095  192.168.20.163        192.168.20.171        TCP      60     60962 > http [RST] Seq=574 Win=0 Len=0
2802 215.154316  192.168.20.163        192.168.20.171        TCP      74     48450 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=429303 TSecr=0 WS=16
2803 215.154397  192.168.20.171        192.168.20.163        TCP      74     http > 48450 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1260 WS=256 SACK_PERM=1 TSval=2143671 TSecr=429303
2804 215.154704  192.168.20.163        192.168.20.171        TCP      60     48450 > http [RST] Seq=1 Win=0 Len=0
2807 215.716852  192.168.20.163        192.168.20.171        TCP      66     60962 > http [FIN, ACK] Seq=574 Ack=1 Win=5840 Len=0 TSval=429375 TSecr=2141685
2826 218.152321  192.168.20.163        192.168.20.171        TCP      74     48450 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=429687 TSecr=0 WS=16
2827 218.152387  192.168.20.171        192.168.20.163        TCP      74     [TCP Previous segment lost] http > 48450 [SYN, ACK] Seq=821395 Ack=1 Win=8192 Len=0 MSS=1260 WS=256 SACK_PERM=1 TSval=2143970 TSecr=429687
2828 218.152669  192.168.20.163        192.168.20.171        TCP      60     48450 > http [RST] Seq=1 Win=0 Len=0
2957 224.152259  192.168.20.163        192.168.20.171        TCP      74     48450 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=430455 TSecr=0 WS=16
2958 224.152379  192.168.20.171        192.168.20.163        TCP      74     [TCP Previous segment lost] http > 48450 [SYN, ACK] Seq=1936893 Ack=1 Win=8192 Len=0 MSS=1260 WS=256 SACK_PERM=1 TSval=2144570 TSecr=430455
2959 224.152722  192.168.20.163        192.168.20.171        TCP      60     48450 > http [RST] Seq=1 Win=0 Len=0
3032 230.130084  192.168.20.163        192.168.20.171        TCP      639    [TCP Retransmission] 60962 > http [FIN, PSH, ACK] Seq=1 Ack=1 Win=5840 Len=573 TSval=431220 TSecr=2141685

奇妙さは 2662 行目から始まりますが、明確な理由もなく、デバイスが RST パケットをサーバーに送信するときですか? なぜそれをするのでしょうか？パケット 2802 ~ 20 秒後に発生する接続の終了を確認できます (これは私のタイムアウト値です)。問題は、デバイスが RST パケットを送信HttpClient.executeしても返されず、そこに留まるということです!

クライアントを構成するときに何かを見逃したのではないでしょうか?

private static DefaultHttpClient newClient()
{
    HttpParams params = new BasicHttpParams();

    ConnManagerParams.setMaxConnectionsPerRoute(params, new ConnPerRouteBean(30));
    ConnManagerParams.setMaxTotalConnections(params, 100);

    HttpProtocolParams.setContentCharset(params, HTTP.DEFAULT_CONTENT_CHARSET);
    HttpProtocolParams.setUseExpectContinue(params, false);
    HttpProtocolParams.setUserAgent(params, "XXXXX XXXXXXXXXX/1.0");
    HttpProtocolParams.setVersion(params, HttpVersion.HTTP_1_1);

    HttpConnectionParams.setConnectionTimeout(params, SOCKET_OPERATION_TIMEOUT);
    HttpConnectionParams.setSoTimeout(params, SOCKET_OPERATION_TIMEOUT);
    HttpConnectionParams.setSocketBufferSize(params, 8192);
    HttpConnectionParams.setStaleCheckingEnabled(params, true);

    SchemeRegistry reg = new SchemeRegistry();
    reg.register(new Scheme("http", PlainSocketFactory.getSocketFactory(), 80));
    reg.register(new Scheme("https", SSLSocketFactory.getSocketFactory(), 443));
    ThreadSafeClientConnManager mgr = new ThreadSafeClientConnManager(params, reg);

    DefaultHttpClient client = new DefaultHttpClient(mgr, params);

    return client;
}

それとも、リクエストの発行方法に関係しているのでしょうか。

private JSONObject performRequest(String url, JSONObject values) 
        throws ClientProtocolException, IOException, JSONException {
    HttpPost httpPost = new HttpPost(url);
    httpPost.setHeader("content-type", "application/json");
    httpPost.setHeader(HTTP.CONN_DIRECTIVE,HTTP.CONN_CLOSE);

    StringEntity requestEntity;
    requestEntity = new StringEntity(values.toString(), HTTP.UTF_8);
    httpPost.setEntity(requestEntity);

    HttpResponse response;
    HttpEntity responseEntity = null;
    String responseString;
    try {
        //this is the line that never returns
        response = _httpClient.execute(httpPost);
        responseEntity = response.getEntity();          
        responseString = EntityUtils.toString(responseEntity);
    } finally {
        if (responseEntity != null)
            responseEntity.consumeContent();
    }
    String d = new JSONObject(responseString).getString("d");
    if (d.length() > 0)
        return new JSONObject(d);
    else
        return new JSONObject();
}

アプリケーションのすべての Web サービス呼び出しに同じものHttpClientが使用され、複数のスレッドがこのクライアントにアクセスできます。a を使用すると、必要なスレッド セーフが提供されると想定していますが、ThreadSafeClientConnManager他に何か見逃している可能性があると思います。

これを解決しようとして、一日中キーボードに頭を悩ませてきました。

編集 これは、特定のIPアドレスを使用した場合ではなく、マシン名をURLとして使用した場合にのみ発生することに言及する必要があると思います。

4

2 に答える 2

0

理解した！デバイスでdhcpcdが実行していた構成スクリプト の 1 つが、使用しているハードウェア/ドライバーと一致していませんでした。スクリプトを修正したところ、バグのある TCP/IP 接続が解決されました。

于 2013-02-08T23:18:58.187 に答える
0

私は以前に非常によく似た問題を抱えていました。サーバーが気に入らないデータが POST 本文に含まれていることが判明しました。試行錯誤を繰り返して、リクエストが通過するまで HttpPost オブジェクトに投げていたものを排除しました。

私にとっては、不適切なキーと値のペアを投入していました。

言い換えれば、あなたの問題は「値」オブジェクトのどこかにあると思います。私の問題は、POST 要求に JSON キー "_b" があることでした。サーバーがタイムアウトしなくなるまで、JSON 値を削除してみてください。

もう 1 つのヒント: これをテストするために、ネットワーク リクエストを繰り返し行うアプリを作成しました。ネットワーク リクエストはタイムアウトになりやすいことがわかっており、タイムアウトになるまでループします。通常、最初の 100 リクエスト以内にタイムアウトします。あなたが同じことをすると役立つかもしれません。

于 2013-02-06T22:47:50.997 に答える