Mostrando entradas con la etiqueta servidor de aplicaciones. Mostrar todas las entradas
Mostrando entradas con la etiqueta servidor de aplicaciones. Mostrar todas las entradas

jueves, noviembre 11, 2010

MySQL y los pools de Threads

jueves, noviembre 11, 2010 por Martín

Estaba repasando algunas entradas en la red sobre MySQL y me he encontrado sobre este artículo que habla del problema que tiene MySQL con la gestión de Threads y en particular con la plataforma Java.

Básicamente el problema es que MySQL se ejecuta como un único proceso. Este proceso crea un Thread para cada una de las conexiones que recibe. En MySQL lo implementaron de este modo porque parece que era realmente rápido. Pero entonces se encontraron con esas plataformas que, como Java, están llenas de pools de conexiones.

Para los que no estéis familiarizados con este concepto, la idea de un pool de conexiones consiste en reservar de antemano las conexiones a recursos externos como son las bases de datos. El conectarse a un recurso externo suele ser una tarea costosa en cuanto a tiempo, y por lo tanto el mantener una estructura de memoria donde se guarden conexiones abiertas que se puedan reutilizar cada vez que nuestro programa accede a ese recurso, parece una buena idea. Cualquier servidor de aplicaciones Java que utilicéis funciona de este modo, Tomcat, Glassfish, WebSphere, WebLogic, el que sea. En otros lenguajes como .NET o Rails también es algo típico.

Y ese es básicamente el problema. La persona que administra el servidor de aplicaciones puede decidir el crear un pool grande: "Voy a reservar 500 conexiones porque vamos a tener muchos usuarios concurrentes". Lo que hará el servidor de aplicaciones es abrir 500 conexiones y mantenerlas abiertas de por vida, aunque no se utilicen. Como consecuencia en MySQL se abren 500 threads, aunque no se utilicen.

Lo ideal sería que MySQL tuviese también un pool de conexiones, pero por ahora va a ser que no. Parece que MySQL 6.0 sí lo va a tener aunque están resolviendo algunos problemillas.

Por cierto si utilizáis MySQL, el blog de Percona tiene dos artículos bastante interesantes:

1 - MySQL utilizado como base de datos NoSQL en memoria SSD
2 - Percona como alternativa a Oracle tras el lio de los precios con InnoDB

lunes, octubre 13, 2008

WebSphere: Para tiempos de crisis, informes afines.

lunes, octubre 13, 2008 por Martín

Yo ya no me sorprendo demasiado con este tipo de informes:



WebSphere v7 parece realmente potente. Tampoco me extrañaría que estuviese realmente en el primer lugar, a fin de cuentas es un buen software, aunque nunca haya conocido a nadie que hable bien de él salvo administradores de sistemas que estén ya acostumbrados al mismo y hayan hecho sus cursos y por lo tanto sean totalmente contrarios a un cambio.

Pero... ¿Geronimo en segundo lugar? No conozco a nadie ni he visto ningún proyecto en Internet que lo utilice. ¿Alguien lo usa realmente? ¿ColdFusion encima de JBoss, Glassfish, WebLogic? ¿WebLogic es el séptimo?....

Como han cambiado las cosas :-)

Visto en TheServerSide. A Rich Sharples de JBoss no le ha parecido bien. A mi me ha parecido gracioso. Pero bueno, ya se sabe que a nadie lo despiden por elegir IBM...

jueves, julio 31, 2008

Portabilidad: Siguiendo la especificación

jueves, julio 31, 2008 por Martín

En Coding the Architecture abrieron un debate muy interesante hace unos días. Es ese tipo de debate en el que miras hacia atrás y ves inevitablemente como tu opinión ha ido cambiado con el tiempo, ya se hacia un lado o hacia el otro. Y es que al final, cada uno contará la historia como le haya ido en la feria.

Hace ocho años, era todo acerca de la portabilidad. Acerca de la especificación. La portabilidad era la gran baza de JEE, y cualquiera que se mantuviese dentro de los límites de la especificación estaba a salvo. ¡Qué gran consuelo cuando tecnologías como EJB 1.1 te garantizaban un camino amargo y tortuoso! Con el tiempo, el debate sobre portabilidad se ha aligerado mucho, y el no seguir la especificación es como el hombre del saco, que te asusta las primeras veces pero que cuando ves que funciona y no pasa nada, pues pierde toda su importancia.

En mi caso, como el de Simon Brown, mi opinión también ha ido cambiando con el tiempo. Pero un poco al contrario. Hace años yo era partidario de no seguir la especificación si llegabas a un punto en el que te estaba restringiendo demasiado. Todavía recuerdo discusiones airadas sobre este tema con amigos y compañeros de trabajo que opinaban justamente lo contrario. El tiempo me ha enseñado que no hay una verdad única respecto a este tema, y que como casi todo, realmente dependerá en el problema que tengas que solucionar, pero que si realmente decides apartarte de la especificación, este debe ser un factor como otro cualquiera que deberás balancear y sobre el que deberás ponderar riesgos y ventajas.

Por ejemplo, hace tiempo, trabajando en un proyecto me encontré con varias partes de una gran aplicación que utilizaban threads directamente para realizar ciertas operaciones. Estas operaciones incluían escrituras en base de datos o envio de mensajes entre otras cosas. ¡Herejía! ¡Uso de threads en managed-systems! El desarrollo había continuado adelante porque era rápido y porque nunca había pasado nada. Sin embargo, a medida que la carga del sistema aumentaba, se pudo observar que se empezaban a perder mensajes, que había transacciones que no se completaban o se hacía rollback de repente, y otro número de efectos insospechados.

El problema era que se habían apartado demasiado de la especificación, y los efectos eran inesperados. Es así de fácil. No estás en la especificación, no tienes garantía de nada. ¡Si es que a veces no la tienes ni cuando sigues la especificación! La solución en este caso fue aprovechar que el servidor implementaba la specificación commonj y devolver esos Threads al contexto que le pertenecían, el contenedor. Eso solucionó todos los problemas.

Ser consciente de que te pueden pasar estas cosas es algo importante a la hora de hacer la decisión de restringirte o no a la especificación. Otro factor muy importante que he podido ver con el tiempo es el negocio al que se dedique la compañía, y como se va a vender la aplicación que se está creando. Muchas compañías que facturan productos ofrecen soluciones basadas en plataformas comunes como Oracle, WebSphere, WebLogic, a la vez que ofrecen otras soluciones de bajo coste basadas en MySQL, PostgreSQL o JBoss. En este caso, es importante mantenerse lo más cerca posible de la especificación, ya que cualquier opción especial que utilizemos la tendremos que reimplementar tanto para la plataforma premium como para la Open Source.

Otro caso con el que me encontrado es con productos que están bajo un servidor de aplicaciones en contreto y necesitan ser migradas a otro para entrar en determinado sector. Un ejemplo típico sería el entrar en la banca donde en algunos sitios te exigirán IBM WebSphere como plataforma de despliegue.

En fin, que al final, como mencionan en los comentarios, es un balance entre los planes de futuro que haya en la aplicación en cuanto a portabilidad y los problemas que nos encontremos al desarrollar. Si existe la posibilidad de despligue en múltiples plataformas, entonces es mejor ir con cuidado; en caso contrario, siempre se puede quebrantar un poco más las normas, pero siempre siendo conscientes de las posibles consecuencias en cuanto a efectos inesperados.

miércoles, abril 30, 2008

Spring Application Server!

miércoles, abril 30, 2008 por Martín


Tenía que pasar. Recuerdo hace unos meses comentando con mi jefe que Spring había recibido capital de riesgo y que eso tenía que significar algo. Nadie pondría 10 millones de dólares en un proyecto basado únicamente en la formación. "- Lo más probable es que aprovechen el tirón de Spring y la inyección de dinero para crear su propio servidor de aplicaciones", comentaba. Aunque la opinión de mis compañeros era contraria, ya que eso sería ir en contra del "J2EE development without EJB" que tanto tiempo ha promovido Rod Johnson.

Y es que para una vez que me sale una predicción tengo que ponerlo por aquí!! Que esto (lo de la predicción) es para celebrarlo!! Aunque mis compañeros también tenían razón ya que el servidor se aparta bastante de lo que actualmente es JEE.

Bueno, el caso es que se puede leer ya en muchas publicaciones, y es que Spring ha lanzado la Spring Application Platform, que según Rod Johnson "is the "first proper Java application server product to appear for the enterprise in ten years" y de la que se puede ya obtener una beta.

La plataforma se construye sobre OSGi (otro enorme impulso también para esta tecnología) y Tomcat, y aunque se pueden desplegar WARs, no se pueden desplegar EARs y no soporta otras especificaciones de JEE como los EJBs. Interesante también lo que comentan en InfoQ sobre la definición de un nuevo formato de despliegue en esta plataforma (PAR) que facilite el trabajo con OSGi.

Quizás nos encontremos ante un punto de inflexión en el mundo de Java y los servidores de aplicaciones. Habrá que ver como evoluciona esta plataforma que además nos dará una idea del calado real de Spring en las empresas, ya que aunque en SpringSource comentan que es enorme y así lo muestran en sus estadísticas, la realidad es que mucha gente utiliza Spring para tareas simples. Queda también en abierto como puede afectar esto a las empresas que basan su stack tecnológico en una única plataforma como BEA, IBM, JBoss, etc. + Spring. ¿Se moverán estas empresas a Spring? ¿Se quedarán con lo que tienen y empezarán a temer el coger cosas de Spring?

El tiempo nos lo dirá. Yo por si acaso voy a dejar de predecir cosas que creo que con una acertada ya es suficiente :)

viernes, marzo 14, 2008

El nuevo modelo de empaquetado de EJBs

viernes, marzo 14, 2008 por Martín

En TheServerSide publican la segunda parte de la serie sobre las novedades en EJB 3.1. Este artículo habla sobre el nuevo TimerService que tiene muy buena pinta, y sobre el nuevo sistema de empaquetado.

Ya he sido crítico con EJB 3.1 antes, y aunque como ya he dicho el nuevo TimerService me gusta bastante, lo cierto es que el nuevo empaquetado no me gusta. Ya no es sólo el hecho de cambiar algo que se ha mostrado efectivo durante todo este tiempo sino más bien el transfondo que hay detrás de este cambio, que no es otro que el mismo que hay tras el cambio de hacer las interfaces opcionales: querer abarcar con EJBs todos los escenarios habidos y por haber.

Quizás es que estoy chapado a la antigua, y que vengo de cuando había EJB 1.x, y que casi todo lo que he hecho con EJBs ha sido con EJB 2.x, pero, ¿no hay nadie más por ahí al que esto...



...no le parezca más simple que esto?



En mi opinión la simplicidad no está en el tamaño de los dibujos, si no más bien en su estructura. Y, nuevamente en mi opinión, el meter todo en un sitio sin separar vista y negocio, el mezclar parte web y parte no necesariamente web, el entremezclar recursos utilizados en diferentes partes y permitir su uso indeferente, no son cosas que hagan una solución mucho más simple. Para mi, es justamente al contrario, la propuesta favorece la confusión. Y eso no es simplicidad.

A mi me gusta el modelo de separación en componentes propuesto por EJBs hasta ahora. Como en el caso de las interfaces, me parece una buena y muy recomendable práctica. El nuevo modelo, totalmente anárquico, está claro que apunta hacia desarrollos minimalistas, buscando el exponer EJBs como una tecnología fresca que se puede utilizar para todo. Sin embargo, ya empiezo a ver proyectos con datasources entremezclados y gente preguntándose dónde se ha declarado cada cosa, incompatibilidades entre recursos, proyectos que de pronto hay que separar en contenedor web y servidor de aplicaciones y se paran durante meses porque se diseñaron para ejecutarse como WARs, etc.

En fin, que parece que sigue la tendencia a lightweight EJBs. La verdad es que lo que noto es que cada vez esto le importa menos a la gente. Los que vivimos la época dorada de los EJBs poco a poco vamos dejando el paso a otras personas que no se tragan lo de que hay que usar EJBs por narices. Hay alternativas, y saben utilizar esas alternativas. Por lo tanto, en mi opinión estos cambios poco ayudan y al abrir el abanico de posibilidades están haciendo todavía más complejo el desarrollo y mantenimiento de aplicaciones basadas en EJBs.

Pero bueno, eso y el avance lento de los servidores de aplicaciones en parte debido a ese relevo generacional serían merecedores de otro post.

viernes, septiembre 14, 2007

WebLogic se prepara para JEE 6

viernes, septiembre 14, 2007 por Martín

Si hay algo que no se le puede negar a BEA es que suelen estar por delante de los demás. Fueron de los primeros (¿el primero?)* en soportar JEE 5, en dar soporte oficial de Spring, en permitir la ejecución de su plataforma sobre un hypervisor, etc. A fin de cuentas, es la ventaja de dedicarse casi exclusivamente a su servidor de aplicaciones.

El caso es que según se puede leer hoy en The Register BEA ha anunciado en su conferencia BEA World que WebLogic 10.3 estrenará un nuevo sistema de módulos que permiten escoger que partes quieres instalar en tu servidor de aplicaciones. De este modo puedes prescindir del contenedor web, o de los módulos de Struts, o del registro UDDI, o cualquier otra cosa que no necesites.

Parece que el instalador para esta versión sólo ocupará 150Mb respecto a los 600Mb actuales. La visión de BEA es que se puedan descargar actualizaciones de los módulos de manera independiente y a través de Internet.

Toda la magia de esto radica en la arquitectura mSA (microService architecture) de BEA que se basa en OSGi y que les ha permitido aislar de manera individual 230 componentes diferentes del servidor de aplicaciones. En la EclipseCon 2007 hubo una presentación (estas son las transparencias) en la que se explicaba más a fondo esta arquitectura de micro-servicios y que ya resumió en su momento Alex Blewitt.

Esto es un primer paso como preparación para JEE 6 aunque por ahora parece que habrá que esperar hasta Marzo del 2008, fecha de lanzamiento de WebLogic Server 10.3.

* Nota: Carlos aclara muy acertadamente en uno de los comentarios que hubo varios servidores de aplicaciones que tenían certificación JEE 5 antes de WebLogic 10.

miércoles, mayo 09, 2007

¿Es Spring el nuevo Java EE?

miércoles, mayo 09, 2007 por Martín

Me ha parecido interesante el artículo de Salil Deshpande, ex CEO of The Middleware Company, publicado en su ex-portal TheServerSide.

Sobre todo porque es un poco un recordatorio de lo que ha pasado en los últimos tres años. Y además tiene toda la razón. ¡Es que parece que fue ayer! El artículo va muy en la línea de este post de hoy mismo de Ignacio Coloma. Hay que reconocer que Spring se ha impuesto al yugo de toda especificación posible, y además con el mérito de haber hecho de AOP una cosa habitual, hasta el punto de que probablemente nadie utilizará AOP si no existiese Spring. Probablemente algo parecido pasará con OSGi que parece ser la nueva baza de los chicos de Interface21.

Pero volviendo al artículo original, personalmente, yo ya sabéis que soy gallego, y en fin, que ni lo uno ni lo otro, que hay sitio para todos. Nosotros utilizamos Spring, pero también tenemos nuestro servidor de aplicaciones que nos ayuda en muchas cosas que de otro modo nos complicarían muchísimo la vida el hacerlas nosotros a mano (léase mensajería ... bueno, ejem, ... ayuda mmmm ... , clustering y failover, integración con third parties, bla bla bla).

De cualqueir modo, el mérito de Spring es impresionante. Sobrevivir manteniéndose al márgen de los estándares y convertirse en estándar de facto tiene realmente muchísimo mérito.

miércoles, abril 04, 2007

BEA lanza WebLogic 10

miércoles, abril 04, 2007 por Martín

Hace un par de días se anunció la disponibilidad general de WebLogic 10. Ninguna sorpresa grande leyendo la la hoja de características. Entre lo más notable: Soporte de Java EE 5/EJB 3.0, soporte oficial de Spring, nueva JPA, Workshop 10 basado en Eclipse y que se puede instalar como plug-in sobre una instalación de Eclipse existente. Todo lo esperado.

Entre lo no esperado, es decir la funcionalidad menos conocida, filtering classloaders (viva!), auto-record en la consola de administración para crear comandos WLST (viva!, me entenderéis en unos días), mejoras en JMS (ojalá!), aplicación de escritorio para monitorizar los servidores (interesante), no hay soporte para plataformas Linux de 64 bits (mmmm??) y no hay soporte para plataformas Solaris (mmmm???).

Esperemos que los dos últimos puntos los arreglen pronto.

jueves, marzo 01, 2007

Liberado Tomcat 6 stable

jueves, marzo 01, 2007 por Martín

Comet aquí vamos. Lo que estabamos esperando muchos ha llegado. No es que jetty sea malo, pero es que Tomcat es como quien dice el estándar de facto y ya se echaba en falta soporte de comet por alguna parte. El soporte ya estaba ahí desde hace rato, pero hasta que el producto no fuese oficialmente estable no lo ibamos a utilizar. Ahora por fin ha llegado el momento. A ver si lo puedo/podemos probar y saco/sacamos algunas conclusiones.

El anuncio de la versión estable.

jueves, febrero 15, 2007

Servidores de aplicaciones y responsabilidades sobre productos

jueves, febrero 15, 2007 por Martín

Durante las últimas semanas en mi trabajo podríamos decir que he aprendido más cosas que en muchos meses. He vivido más de una situación que puedo garantizar que no me esperaba al llegar aquí, unas buenas y otras malas. Supongo que de todas iré hablando, en su debido momento.

Pero ahora mismo escribir un poco sobre la responsabilidad de los fabricantes de servidores de aplicaciones (léase IBM, BEA, Sun, Oracle, jboss,...). En mi compañía durante los últimos meses hemos localizado más de 10 memory leaks en el servidor de aplicaciones que utilizamos.

El proceso siempre ha sido el mismo, se localiza un memory leak, se busca durante un par de semanas la causa, no se encuentra nada y al final se deduce que es un fallo del servidor. Llamas al proveedor, te lo solucionan o te mandan algún experto, estos expertos están por ahí analizando todo, y al final nos dan un parche. Hemos llegado a alguna situación en la que teníamos gente parcheando en tiempo real el código de ese servidor de aplicaciones en concreto. Ahí, delante de nosotros, el código fuente del todopoderoso.

Pero dejando a un lado estas anéctodas, no deja de ser frustrante el pasarte semanas buscando errores en tu código hasta descubrir que es un fallo en el servidor en el que has confiado, que resulta que no era tan bueno como parecía. Inviertes enormes cantidades de recursos en depurar y perfilar errores que al final al que ayudan es al fabricante del servidor de aplicaciones porque a la hora de la verdad el cliente tendrá la percepción de que los problemas están en las aplicaciones y no en el servidor. Y a todo esto hay que añadirle que cuando te mandan expertos y consiguen un parche, encima has tenido que pagar por ello, faltaría más. Negocio redondo: invierto mi tiempo buscando tu error y te pago para que lo arregles.

Lo malo es que esto tiene consecuencias fatales para las compañías. Retrasos de meses en las aplicaciones, sensación de fragilidad en dichas soluciones, sensación hacia el exterior de imposibilidad de lanzar productos, desconfianza y posible perdida de contratos, etc. ¿Cómo debe actuar el proveedor de aplicaciones en estos casos?

Lo único que se me ocurre es:
  • Solución 1: Nosotros somos malisimos. Que levante la mano y asuma su responsabilidad ante los clientes. Que visiten clientes y expliquen lo sucedido, o lo publiquen de alguna manera.
  • Solución 2: Ellos son buenísimos. Que publicite y refuerze las líneas de marketing de la empresa fortaleciendo su posición y la de un producto que ha podido quedar dañado de cara al público final.


El que tenga más ideas que levante la mano :)