How to fast fail JBoss (ie System.exit()) during container initialization when exception is propagated to ServerImpl.doStart()

Specifically, consider the case where JBoss attempts to open a socket on 1099 during ServiceMBeanSupport (rmi) initialization, but port 1099 is already taken.

Current behavior is that the exception is system.err'd and JBoss continues to initialize. Later, during application runtime, a jndi lookup causes an execution thread to hang -- not good and more difficult to diagnose than a failed container initialization.

So the question is, how to fast fail JBoss on initialization exception?

Here's the trace:

java.net.BindException: Address already in use: JVM_Bind
 at java.net.PlainSocketImpl.socketBind(Native Method)
 at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:359)
 at java.net.ServerSocket.bind(ServerSocket.java:319)
 at java.net.ServerSocket.<init>(ServerSocket.java:185)
 at开发者_运维问答 javax.net.DefaultServerSocketFactory.createServerSocket(ServerSocketFactory.java:170)
 at org.jnp.server.Main.initBootstrapListener(Main.java:331)
 at org.jnp.server.Main.start(Main.java:282)
 at org.jboss.naming.NamingService.startService(NamingService.java:236)
 at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
 at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
 at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
 at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
 at $Proxy0.start(Unknown Source)
 at org.jboss.system.ServiceController.start(ServiceController.java:417)
 at org.jboss.system.ServiceController.start(ServiceController.java:435)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
 at $Proxy4.start(Unknown Source)
 at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
 at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:755)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
 at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
 at $Proxy5.deploy(Unknown Source)
 at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
 at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
 at org.jboss.Main.boot(Main.java:200)
 at org.jboss.Main$1.run(Main.java:464)

You can't, to my knowledge, but you're right, it is annoying when it does this.

If you're running this on *nix, my suggestion would be to write a bash script which checks for port availability in advance, and only launches JBoss if they're available. Maybe you could do something similar with cygwin on windows.

I also agree that jboss could fail the startup, just as Apache httpd does.

A script to pre-check may not detect that after the check and before JBoss grabs the port another process grabs it. Maybe a rare situation, but possible and also hard to detect.

Since JBoss does not offer to fail when a port cannot be opened, I suggest monitoring the logging. It could be helpful to configure log4j to alert via mail|SNMP|whatever if this situation occurs and propert management could kick in straight away.