SocketProcessId.getpid could not get unique port

Intentando ejecutar JBoss 5 (la versión para Java 6) en Ubuntu me apareció el siguiente error:

2009-02-01 02:49:32,115 INFO  [com.arjuna.ats.jbossatx.jta.TransactionManagerService] (main) Setting up property manager MBean and JMX layer
2009-02-01 02:49:32,788 DEBUG [com.arjuna.ats.arjuna.logging.arjLoggerI18N] (main) [com.arjuna.ats.arjuna.recovery.TransactionStatusManager_1] - Starting service com.arjuna.ats.arjuna.recovery.ActionStatusService on port 4713
2009-02-01 02:49:32,812 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (main) Error installing to Create: name=TransactionManager state=Configured com.arjuna.ats.arjuna.exceptions.FatalError: [com.arjuna.ats.internal.arjuna.utils.SocketProcessId_2] - SocketProcessId.getpid could not get unique port.
 at com.arjuna.ats.internal.arjuna.utils.SocketProcessId.getpid(SocketProcessId.java:105)
 at com.arjuna.ats.arjuna.utils.Utility.getpid(Utility.java:277)
 at com.arjuna.ats.arjuna.common.Uid.(Uid.java:105)
 at com.arjuna.ats.arjuna.utils.Utility.getProcessUid(Utility.java:289)
 at com.arjuna.ats.internal.arjuna.recovery.TransactionStatusManagerItem.(TransactionStatusManagerItem.java:366)
 at com.arjuna.ats.internal.arjuna.recovery.TransactionStatusManagerItem.createAndSave(TransactionStatusManagerItem.java:84)
 at com.arjuna.ats.arjuna.recovery.TransactionStatusManager.start(TransactionStatusManager.java:145)
 at com.arjuna.ats.arjuna.recovery.TransactionStatusManager.(TransactionStatusManager.java:72)
 at com.arjuna.ats.arjuna.coordinator.TxControl.(TxControl.java:355)
 at com.arjuna.ats.jbossatx.jta.TransactionManagerService.create(TransactionManagerService.java:178)

(y continúa...)

No sé exactamente cuál era el problema, pero lo pude solucionar mapeando al IP correcto el nombre de host que devuelven los comandos "hostname" y "hostname -f".

Ejemplo:

#~ hostname -f
unhost.example.com

Antes de solucionar el problema, "unhost.example.com" tenía asociado un IP incorrecto (o sea, un IP que no correspondía a ningun IP del sistema). Para solucionar el problema asocié a "unhost.example.com" el IP de la placa de red.

Esta cuestión también impide que Glassfish 2.1 arranque correctamente.

Ejemplo de mod_gzip de Apache + JBoss

Un ejemplo de configuración de mod_gzip. Dos problemas con los que me topé mientras lo configuraba:

- Hacerlo funcionar con contenido tomado de un servidor JBoss vía AJP: para esto debemos utilizar:

mod_gzip_item_include handler ^jakarta-servlet

- Algunos contenidos no se comprimian, aunque parecía estar todo bien configurado: esto es debido a que la expresión regular configurada era:

^text/html$

y debía ser:

^text/html

porque los encabezados suelen incluir información de encoding, por ejemplo:

text/plain; charset=us-ascii



Ejemplo completo

<ifmodule mod_gzip.c>
    mod_gzip_on                     Yes
    mod_gzip_can_negotiate          No
    mod_gzip_dechunk                Yes
    mod_gzip_handle_methods         GET POST

    # 512k
    mod_gzip_maximum_file_size      524288

    # 200k
    mod_gzip_maximum_inmem_size     204800

    mod_gzip_item_include   handler ^jakarta-servlet
    mod_gzip_item_include   file    \.html$

    # Si usamos ^text/html$ (con $ al final) entonces estaremos excluyendo
    # los mime que incluyen el encoding (utf8, etc) junto a text/html
    mod_gzip_item_include   mime    ^text/html
    mod_gzip_item_include   mime    ^text/plain
    mod_gzip_item_include   mime    ^text/javascript
    mod_gzip_item_include   mime    ^text/css
    mod_gzip_item_include   uri     ^/intranet/app
    mod_gzip_item_exclude   mime    ^image/
</ifmodule>

Tomcat, Apache y "All threads (200) are currently busy"

Por alguna cuestión cuyo origen no he podido detectar, me ha traido muchos problemas un apache que se conecta a Tomcat (JBoss 4) utilizando AJP. Luego de unos días, Tomcat empezó a generar estos mensajes de error:

ERROR [org.apache.tomcat.util.threads.ThreadPool] All threads (200) are currently busy, waiting. Increase maxThreads (200) or check the servlet status

Pero definitivamente el problema no está en la cantidad de threads necesarios para servir el sitio, sino que por alguna razón las conexiónes quedaban "ocupadas", y en la página de status de Tomcat aparecían todos los threads como en "Stage KeepAlive"...
La solución es bastante sencilla, sólo hace falta configurar el timeout (connectionTimeout) en el contector AJP:

<!-- A AJP 1.3 Connector on port 8009 -->
<Connector port="8009" address="${jboss.bind.address}" emptysessionpath="true" enablelookups="false" redirectport="8443" protocol="AJP/1.3" connectiontimeout="60000">
</Connector>


Seteando el timeout en 60 segundos solucioné el problema.

JBoss IDE: nightly builds

Para aquellos que (como yo) están ansiosos por la llegada de la versión 2 de JBoss IDE (por estar basado en Eclipse 3.3 y el soporte para JBoss Seam), pueden ir chequeando la lista de correo y bajar y probar los "nightly builds".