Timeouts avec instance singleton de DefaultHttpClient

Question

J'utilise un singleton instance de DefaultHttpClient conjointement avec PoolingClientConnectionManager pour effectuer un certain nombre cconsiderable (multiple par seconde) des opérations HTTP de manière multithread. Mon code est essentiellement:

final HttpParams httpClientParams = new BasicHttpParams(); 
httpClientParams.setParameter("http.protocol.version", HttpVersion.HTTP_1_1); 
HttpConnectionParams.setConnectionTimeout(httpClientParams, 700); 
HttpConnectionParams.setSoTimeout(httpClientParams, 700); 
DefaultHttpClient client = new DefaultHttpClient(poolingClientConnectionManager, httpClientParams); 

Je vais ensuite accéder à l'objet client de plusieurs threads en parallèle. Mon problème est, que les délais d'attente ne sont pas respectés et j'ai des requêtes HTTP qui prennent beaucoup plus de temps que les 700ms spécifiés.

• Est-il sûr de définir le délai d'attente sur le client comme je le fais ci-dessus?
• Est-il sûr d'utiliser une instance singleton de DefaultHttpClient pour de nombreuses demandes parallèles?

Answer 1

• Est-il sûr de définir le délai d'attente sur le client comme je le fais ci-dessus?

Oui, c'est sans danger. Cependant, les paramètres de niveau HttpClient représentent les paramètres par défaut hérités par toutes les demandes. Il ne faut pas se mêler de ces paramètres lors de l'exécution. Il est généralement préférable d'utiliser les paramètres de niveau de requête pour configurer les demandes individuelles.

• Est-il sûr d'utiliser une instance singleton de DefaultHttpClient pour de nombreuses demandes parallèles?

Non seulement sûr mais aussi fortement conseillé. En partageant la même instance HttpClient, des requêtes individuelles peuvent être exécutées plus efficacement en réutilisant un pool partagé de connexions persistantes.

Veuillez également vous assurer que vos attentes concernant le comportement du délai d'attente sont correctes. Les valeurs de délai d'attente représentent la période maximale d'inactivité entre deux opérations d'E/S consécutives, et non la durée d'exécution totale maximale de la requête.