Как быстро выполнить сбой JBoss (т.е. System.exit ()) во время инициализации контейнера, когда исключение распространяется на ServerImpl.doStart ()

Question

В частности, рассмотрим случай, когда JBoss пытается открыть сокет на 1099 во время инициализации ServiceMBeanSupport (rmi), но порт 1099 уже занят.

Текущее поведение: исключение system.err'd, и JBoss продолжает инициализацию.Позже, во время выполнения приложения, поиск jndi приводит к зависанию потока выполнения - что не очень хорошо и труднее диагностировать, чем неудачная инициализация контейнера.

Итак, вопрос в том, как быстро завершить JBoss при исключении инициализации?

Вот след:

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)

Answer 1

Насколько мне известно, вы не можете, но вы правы, это раздражает, когда это происходит.

Если вы используете это на * nix, я бы предложил написать сценарий bash, который заранее проверяет наличие портов и запускает JBoss, только если они доступны. Может быть, вы могли бы сделать что-то подобное с Cygwin на Windows.

Answer 2

Я также согласен с тем, что jboss может дать сбой при запуске, как это делает Apache httpd.

Скрипт для предварительной проверки может не обнаружить этого после проверки и до того, как JBoss захватит порт, другой процесс захватит его.Может быть, редкая ситуация, но возможная, а также трудно обнаруживаемая.

Так как JBoss не предлагает сбой, когда порт не может быть открыт, я предлагаю следить за ведением журнала.Может быть полезно настроить log4j для оповещения по почте | SNMP | независимо от того, возникает ли такая ситуация, и управление свойствами может сразу же включиться.