HttpWebRequest Timeout in HTTP Get
En estos últimos días he tenido un problema bastante curioso. Era una aplicación multi-hilo (50 hilos simultáneos de ejecución) que realizaba peticiones HTTP Get a distintos servidores. El problema es que se presentaban bastante timeouts en las peticiones HTTP y sin embargo el servidor estaba en un correcto funcionamiento.
El código era algo como esto:
public static string Get2(string uri)
{
string responseData = string.Empty;
WebRequest request = WebRequest.Create(uri) as HttpWebRequest;
request.Method = "GET";
request.Timeout = 35000;
using(HttpWebResponse response = (HttpWebResponse)request.GetResponse() as HttpWebResponse)
{
using(Stream dataStream = response.GetResponseStream ())
{
using(StreamReader reader = new StreamReader (dataStream))
{
responseData = reader.ReadToEnd();
}
}
}
return responseData;
}
Tras buscar, encontré bastantes links y este bastante interesante.
El problema era que .NET sólo permite 2 conexiones HTTP a cada sitio, tal y como establece el el protocolo HTTP1.1. Para aumentar este número, lo único que hace falta es incluir esta configuración en el app.config o web.config.
<connectionManagement> <addaddress="*"maxconnection="40"/> </connectionManagement>
Consejos para evitar bloqueos e interbloqueos
Interesante post con unas conclusiones que merecen tenerse en cuenta:
- Nunca bloquees por un objeto que no sea estático:
Eso solo serviría para proteger los miembros de esa instancia concreta, y rara vez es esto lo que deseamos con un lock.
- Nunca hagas un lock sobre un objeto publico:
Como se explico previamente, el lock sobre el objeto publico significa que otra parte de la aplicación puede hacer un lock sobre el mismo objeto y ocasionar un interbloqueo.
- Sobre todo, la mas importante de todas… Nunca hagas un lock sobre un System.RuntimeType o System.Type:
Ya sabéis, si leísteis la parte teórica, que estos tipos son Marshal-by-bleed, lo que significa que se comparten entre dominios de aplicación diferentes. El riesgo de interbloqueo es enorme, y no puedo pensar en un solo escenario en que tenga sentido hacer ese bloqueo.
Firefox plugin para Desarrollo
Para desarrollo web.
- Firebug.
- Web Developer.
- Yslow.
- Page Speed.
Para desarrollo web móvil.
- UserAgent Switcher.
- wmlbrowser.
- xHtml Mobile Profile.
Para HTTP.
- Live Http Headers.
- Tamper Data.
W3C Device API
La w3c comienza el desarrollo de un borrador, Device API, para definir una serie de APIs que se ejecutarían en el cliente y permitirían acceder a determinada funcionalidad del dispositivo, como el calendario, los contactos, la cámara (esperemos que también la localización) y así como definir un marco de seguridad.
Muy en la línea y un paso atrás que la iniciativa Bondi, esperemos que de un lado u otro al final los desarrolladores podemos acceder a esta funcionalidad desde el navegador. Si no aparece una solución pronto, veremos como se imponen las funciones de algún navegador específico, como el de iphone o Android.
Estadísticas de admob html vs xhtml MP
Merece la pena comentar las estadísticas de admob, en las cuales (además de en multitud de sitios) se sobresalta que el iphone supera con creces a los demás competidores.
Sin embargo, en mi opinión esas gráficas son relativamente parciales. Es muy normal que desde otros dispositivos (e incluso el iphone) se accedan a páginas específicas para móviles (ya sean wml o xhtml mp) que ofrecen unos tiempos de respuesta muchos más rápidos. Además de esto se está desechando el tráfico que procede de determinadas aplicaciones o widgets que es bastante usado en determinados terminales ya que se hace un uso más eficiente de la conexión.
Push email con Funambol
Con las herramientas cliente/servidor de Funambol, podemos tener email push y sincronización en cualquier dispositivo móvil. Además poseen una aplicación web, myFunambol, para no tener que realizar la instalación de servidor.
Además en el siguiente blog (en el que también explican como usar el navegador de la blackberry sin BIS), recomiendan el siguiente plugin que integra el correo en la blackberry. Parece una mejor solución que usar Shangmail con sus servidores alojados en China.
.Net Profilers
Un pequeño recordatorio con los profilers de .net que he estado probando.
- nprof (y en google code) bastante antiguo y con algunos cuelgues, pero opensource.
- dotTrace Profiler, sin duda alguna el mejor que probé.
- Profile Sharp, también opensource.
Protocol Buffers en C#
Leyendo el siempre interesante blog de Ayende, descubro la manera en la google serializa sus datos: Protocol Buffers, y su implementación por Jon Sket en c#.
Las nuevas características de firefox
Tengo que decir que estoy maravillado con el blog de Aza Raskin de Mozilla, sus últimos posts me están encantando y sobre todo viendo como será el futuro Firefox. Estoy deseando tener a Ubiquity en mi barra de direcciones (e integrarlo con lanzadores de aplicaciones como Google Desktop o Launchy). Además de esto, me parece muy acertado como el comando nueva pestaña está evolucionando, aunque esto es algo que comenzó con Chrome y que parece que todos los navegadores comenzarán a imitar y ampliar.
Algo que no termino de ver, al menos por la similitud con iTunes, es como se quiere cambiar la manera de acceder a la información sustituyendo las pestañas (aunque estoy de acuerdo que tener 20 pestañas abiertas no es muy útil). Creo que hay que buscar nuevos medios para interactuar con toda la información que nos brinda el navegador e incluso el desarrollo de agentes para que automatizar el acceso a la información.
Desde luego que Firefox no se duerme en los laureles frente al nuevo Internet Explorer 8.1.
