2012-03-16 9 views
5

Hola, ya hice estas preguntas, pero esta vez verifico ese método para permitir que todo el certificado no esté causando problemas.Android - Periódicamente se produce el tiempo de espera de HttpClient

Desarrollo una aplicación que también está en iPhone. El problema es con las solicitudes de API. Configuro los tiempos de espera para todas las solicitudes. A veces ocurre amablemente un descanso de 30 a 60 segundos. Parece que esta aplicación hace solicitud de pareja y luego se rompe, todo el tiempo de espera, después de 45 segundos todo está bien.

No sé si esto es problema de servidor o android.

Este problema no se produce en el iPhone con iOS 5, pero también apear en IOS 4.

puedo comprobar si hay HttpClient y también fot HttpsURLConnection.

La conexión es https, también estaba intentando directamente la dirección IP.

Todas las solicitudes tienen el mismo problema, todas las solicitudes se realizan en tareas asíncronas.

Todos ellos tiene el mismo aspecto:

DefaultHttpClient client = new HttpSupport().getNewHttpClient(); 

    client.getCredentialsProvider().setCredentials(new AuthScope(AuthScope.ANY_HOST,AuthScope.ANY_PORT),new UsernamePasswordCredentials(user, pass)); 

    HttpGet httget = new HttpGet("xxxxxxxxxxxxxxxxxxxxxxx"); 
    httget.setHeader("Accept", "application/json"); 

    HttpResponse respond = null; 

    try 
    { 
     respond = client.execute(httget); 
    } 
    catch (ClientProtocolException e) 
    { 
     Log.e(TAG,"getEvents, ClientProtocolException"); 
    } 
    catch (IOException e) 
    {   
     Log.e(TAG,"getEvents, IOException: " + e.getMessage()); 
    } 

El código dor mi clase HttpSupport está en mi pregunta anterior: Android - API Requests

Es puede ser culpa del servidor? Gracias por cualquier ayuda.

Recientemente noté que la aplicación se cuelga en client.execute ... intente hacer esto: android httpclient hangs on second request to the server (connection timed out), pero no será de ayuda. Tal vez no es una falla de API, pero Android como es. Esta aplicación apunta la API muy a menudo, pero para la mayoría de las solicitudes todo está bien.

Todavía no puede deshacerse de los 30-45 segundos de suspensión.

Hoy probé de nuevo la aplicación y noté que el error ocurre solo en la conexión wi-fi en la tableta Samsung con 3.2. En Wildfire con 2.3.7 (wi-fi y 3g) todo parece estar bien. No estoy diciendo que el problema no ocurra en el móvil, pero mientras estaba probando no he notado tiempos de espera.

Respuesta

3

Su cliente tiene un tiempo de espera demasiado corto: en una conexión móvil, debe esperar hasta 30 segundos para formar la conexión y 30 segundos más para recibir una respuesta.

Su código (a través de su enlace):

int timeoutConnection = 3000; 
     HttpConnectionParams.setConnectionTimeout(params, timeoutConnection); 
     // Set the default socket timeout (SO_TIMEOUT) 
     // in milliseconds which is the timeout for waiting for data. 
     int timeoutSocket = 5000; 
     HttpConnectionParams.setSoTimeout(params, timeoutSocket); 

Es en milisegundos. Por lo tanto, el tiempo de espera de conexión es de 3 segundos y la respuesta es de 5 segundos.

Haría ese 30000 y 60000 respectivamente.

Además, si desea descartar cualquier problema del servidor, instale un proxy HTTP como fiddler2 y úselo para mostrar cada solicitud HTTP/HTTPS y verá la respuesta de cada servidor. A continuación, verá si el cliente o el servidor se comporta mal.

+0

¿Estás seguro de los tiempos? Tengo este problema incluso si uso dispositivos en wi-fi y los chicos de api me envían una respuesta 'veces, cada menos de 0,5 segundos. – goodm

+0

No es 100% su problema, pero definitivamente son demasiado cortos para todos los escenarios de conectividad que pueda enfrentar. Pero, es por eso que recomiendo correr con Fiddler, esto ayudará a identificar su problema. – peterept

+0

Lamentablemente, incluso si cambio los tiempos de espera, no solucionará mi problema, simplemente extiende el tiempo de espera. – goodm

2

No tengo una explicación clara para su problema, pero eché un vistazo a su código y creo que hay algún error en su código que puede ocultar algún defecto oculto que el desarrollador debe solucionar en tiempo de compilación. de dejarlos y dejarlos filtrarse en tiempo de ejecución.

En su HttpSupport.getNewHttpClient() aplicación:

public DefaultHttpClient getNewHttpClient() { 
    try { 
    ... ... 

    ClientConnectionManager ccm = new ThreadSafeClientConnManager(params, registry); 

    return new DefaultHttpClient(ccm, params); 
    } catch (Exception e) { 
    return new DefaultHttpClient(); 
} 

}

Hay que devolver un ejemplo HttpClient tanto en tratar de bloque catch, donde el uno del bloque try devuelve una robusta HttpClient que cuenta correcta protocolo, credenciales, etc. utilizados para acceder al servidor HTTP remoto. ¿Cuál es el punto de retorno de otro HttpClent desnudo en el bloque catch cuando ocurrió la excepción? La excepción generalmente significa que ocurrió algún error esperado y el desarrollador debe ocuparse de ello en el momento de la compilación, lo que hiciste fue simplemente ignorar todas las advertencias útiles y dejarlas filtrar durante el tiempo de ejecución de la aplicación, y aún peor, sin visibilidad para saber qué sucedió en la ejecución hora.

Así que el primer intento de identificar su problema es cambiar el código para manejar la excepción correctamente, simplemente imprima el seguimiento de la pila de excepción y encuentre cuáles son los posibles problemas al crear/inicializar su HttpClient.

Otro punto que me gustaría mencionar es que usted crea/inicializa HttpClient bajo demanda, es decir, crea e inicializa una nueva instancia de HttpClient cada vez que necesita enviar una solicitud HTTP, que puede no estar relacionada con su problema pero es ineficiente IMO.

Mi sensación es que su problema probablemente esté relacionado con la creación/inicialización de HttpClient en entornos multihilo (como usted dijo que usa AsyncTask), ya que HttpClient no es seguro para subprocesos. espero que esto ayude.

+0

Sí, estaba pensando en esto, pero cuando puse Log.e ("HttpClient", e.toString()); en la excepción de captura, nunca ocurre en mis Registros. Entonces esto no es la causa de esto. Empecé a suponer que esto es culpa del servidor, no de la aplicación. – goodm

+0

Sin embargo, devolver HttpClient desnudo en bloque catch es una absoluta tontería. ¿Cómo genera su aplicación una solicitud HTTP? ¿Hay algún lugar en su aplicación que genere y genere múltiples solicitudes HTTP simultáneamente (a través de AsyncTask)? – yorkw

Cuestiones relacionadas