miércoles, 12 de noviembre de 2008

Uso de Apache como proxy inverso de Glassfish V2

Aunque en muchos escenarios sería más que discutible... una práctica bastante habitual es tener un proxy inverso que sirva el contenido estático, haga balanceo y algunas reglas de seguridad delante de nuestro Glassfish.

Como digo es algo muy discutible en el 75% de los casos, la mayor parte de al gente lo hace como "buena práctica" y punto, pero no siempre hace falta y a cambio se complica un poquito más el sistema... Si se hace sólo por rendimiento, a día de hoy no tiene sentido porque Grizzly (el motor http de Glassfish) es muy óptimo y lo que se gana por un lado se pierde en las comunicaciones entre el proxy inverso y la aplicación final. Pero si se hace por seguridad (suele ser la excusa pero en la mayor parte de los escenarios no aporta nada, sobre todo si se ejecuta en la misma máquina que el Glassfish, je, je), o por balanceo de cargas o por caches, etc, etc. Entonces me callo. Sí que hace falta. Y es muy buena idea que sea Apache el servidor web escogido.

En cualquier caso. ¿Cómo hacer que un Apache 2 / 2.2 sea el frontal HTTP para nuestro Glassfish?

Espero que en V3 den soporte bien dado, para Glassfish V2 hay que hacerlo con mod_jk en el lado Apache y copiando unos jars de Tomcat 5.5 en el lado Glassfish. Sí lo habéis leído bien...

En todos estos enlaces están las instrucciones:

Pero, oh sorpresa, resulta que en los últimos meses las cosas han cambiado. Tomcat 6 no trae ningún tomcat_apj.jar (sino que lo han integrado en tomcat_coyote.jar) y la implementación en las versiones más recientes de Tomcat 5.5 no es compatible con Glassfish V2. ¿Te sale esta excepción al hacer una request?:


java.lang.NoSuchFieldError: USE_CUSTOM_STATUS_MSG_IN_HEADER
at org.apache.jk.common.JkInputStream.appendHead JkInputStream.java:283)
at org.apache.jk.core.MsgContext.action(MsgContext.java:267)
at org.apache.coyote.Response.action(Response.java:221)
at org.apache.coyote.Response.sendHeaders(Response.java:416)
at org.apache.coyote.tomcat5.OutputBuffer.doFlush(OutputBuffer.java:355)
at org.apache.coyote.tomcat5.OutputBuffer.close(OutputBuffer.java:321)
at org.apache.coyote.tomcat5.CoyoteResponse.finishResponse(CoyoteResponse.java:578)
at org.apache.coyote.tomcat5.CoyoteAdapter.afterService(CoyoteAdapter.java:318)


Si esta es la excepción, esta es tu solución: coge el tomcat_apj.jar de Tomcat 5.5.23 y no de ninguna posterior (actualmente van por la 5.5.27 en la rama 5.5). Y funciona perfectamente.

Al César lo que es del César, a mi me ha salvado la vida esta entrada: http://www.albeesonline.com/blog/2008/10/10/javalangnosuchfielderror-use_custom_status_msg_in_header/

Todo una guarrada, ¿verdad? Lo cierto es que dice poco del equipo de diseño de Glassfish, es como si no hubieran pensado en implantaciones "para el mundo real"... ¿?

No hay comentarios: