Problemas de tiempo de espera de conexión HTTP

Estoy funcionando en un problema cuando intento utilizar el HttpClient que conecta con una url. La conexión http tarda más tiempo en el tiempo de espera, incluso después de establecer un tiempo de conexión.

int timeoutConnection = 5000; HttpConnectionParams.setConnectionTimeout(httpParameters, timeoutConnection); int timeoutSocket = 5000; HttpConnectionParams.setSoTimeout(httpParameters, timeoutSocket);

Funciona perfectamente la mayor parte del tiempo. Sin embargo, de vez en cuando, la conexión http se ejecuta para siempre e ignorar el setconnectiontimeout , especialmente cuando el teléfono está conectado a wifi, y el teléfono estaba inactivo.

Así que después de que el teléfono esté inactivo, la primera vez que intento conectar, la conexión http ignora el setconnectiontimeout y se ejecuta para siempre, después de que lo cancele y vuelva a intentar, funciona como encanto cada vez. Pero esa vez que no funciona crea un error threadtimeout , threadtimeout intentado usar un hilo diferente, funciona, pero sé que el hilo se está ejecutando durante mucho tiempo.

Entiendo que el wifi va a dormir en reposo, pero no entiendo por qué es ignorar el setconnectiontimeout .

Cualquier persona puede ayudar, identificación realmente apreciada.

No estoy seguro si esto te ayuda, sin embargo creo que vale la pena compartir aquí. Mientras que juega con la materia del timeout encontré allí es un tercer tipo del timeout que puedes asignar:

 // the timeout until a connection is established private static final int CONNECTION_TIMEOUT = 5000; /* 5 seconds */ // the timeout for waiting for data private static final int SOCKET_TIMEOUT = 5000; /* 5 seconds */ // ----------- this is the one I am talking about: // the timeout until a ManagedClientConnection is got // from ClientConnectionRequest private static final long MCC_TIMEOUT = 5000; /* 5 seconds */ ... HttpGet httpGet = new HttpGet(url); setTimeouts(httpGet.getParams()); ... private static void setTimeouts(HttpParams params) { params.setIntParameter(CoreConnectionPNames.CONNECTION_TIMEOUT, CONNECTION_TIMEOUT); params.setIntParameter(CoreConnectionPNames.SO_TIMEOUT, SOCKET_TIMEOUT); params.setLongParameter(ConnManagerPNames.TIMEOUT, MCC_TIMEOUT); }

He encontrado el mismo problema, supongo que tal vez el Android no es compatible con este parámetro. En mi caso he probado los tres parámetros para el ThreadSafeClientConnManager

 params.setParameter( ConnManagerPNames.MAX_CONNECTIONS_PER_ROUTE, new ConnPerRouteBean(20) ); params.setIntParameter( ConnManagerPNames.MAX_TOTAL_CONNECTIONS, 200 ); params.setLongParameter( ConnManagerPNames.TIMEOUT, 10 ); ThreadSafeClientConnManager connmgr = new ThreadSafeClientConnManager( params );

El primero y el segundo funcionaron bien, pero el tercero no funcionó como se documentó. No se ha producido ninguna excepción y el subproceso de ejecución se bloqueó indefinidamente cuando se ejecuta DefaultHttpClient # execute ().

Consulte http://hc.apache.org/httpcomponents-client-ga/tutorial/html/connmgmt.html#d4e650
"… Se puede asegurar que el gestor de conexión no bloquee indefinidamente en la operación de petición de conexión estableciendo 'http.conn-manager.timeout' en un valor positivo Si la petición de conexión no puede ser atendida dentro del período de tiempo especificado ConnectionPoolTimeoutException será Lanzado

 Thread t=new Thread() { public void run() { try { Thread.sleep(absolutetimeout); httpclient.getConnectionManager().closeExpiredConnections(); httpclient.getConnectionManager().closeIdleConnections(absolutetimeout,TimeUnit.MILLISECONDS); httpclient.getConnectionManager().shutdown(); log.debug("We shutdown the connection manager!"); } catch(InterruptedException e) {} } }; t.start(); HttpResponse res= httpclient.execute(httpget); t.interrupt();

¿Es eso en la línea de lo que todos sugieren?

No estoy exactamente seguro de cómo cancelar la ejecución una vez que ha comenzado, pero esto parecía funcionar para mí. No estoy seguro de cuál de las tres líneas del hilo hizo la magia, o si fue alguna combinación de todas ellas.

Usted puede gestionar los tiempos de espera usted mismo, de esta manera usted puede estar seguro de que no importa el estado de la conexión, a menos que reciba una respuesta aceptable, que su tiempo de espera se disparará y la solicitud http será abortada.

He tenido problemas similares con los tiempos de espera en android. Para resolverlo lo que hice fue utilizado los comandos para no dejar que el teléfono inactivo mientras estaba tratando de establecer una conexión y durante cualquier lectura o escritura a la conexión. Su probablemente vale la pena una oportunidad en este caso también.

Aunque no he visto esto en la plataforma Android, he visto cosas similares en otras plataformas y la solución en estos casos es gestionar el tiempo de espera. Inicie otro hilo (el hilo de tiempo de espera) cuando haga su solicitud. El hilo de tiempo de espera cuenta el tiempo requerido. Si el tiempo de espera expira antes de recibir cualquier dato, el hilo de tiempo de espera cancela la solicitud original y vuelve a intentarlo con una nueva solicitud. Más difícil de codificar, pero al menos sabes que funcionará.

De su fragmento no está claro si establece los tiempos de espera antes de llamar a HttpClient.executeMethod(..) . Así que esta es mi suposición.

Bueno, si usted está ocioso / multitarea a otra aplicación, entonces el hilo que se está ejecutando podría ser detenido y destruido. Tal vez debería poner el código de conexión dentro de un servicio en su lugar ?:

http://developer.android.com/reference/android/os/AsyncTask.html http://developer.android.com/reference/android/app/IntentService.html

¿Cómo se hace la conexión HTTP? Esto parece un problema de subprocesamiento. Si está utilizando un subproceso de fondo, el subproceso puede ser eliminado junto con cualquier tiempo de espera registrado. El hecho de que funcione la próxima vez me dice que su código funcionará, si realiza la llamada en un componente android y gestiona el WAKE_LOCK en él mismo. De todos modos por favor, postear más información sobre el mecanismo de llamada?

El problema podría estar en el cliente HTTP de Apache. Consulte HTTPCLIENT-1098 . Arreglado en 4.1.2.

La excepción de tiempo de espera intenta invertir DNS la IP, para fines de registro. Esto tarda un tiempo adicional hasta que la excepción se dispara realmente.