JBoss 4.0.5 Appserver running as a service shutsdown

[vamsin]

We install JBoss as a windows service with a "Local System Account" and "Allow service to interact with Desktop" options.
When I login and start the service and then log off, the service shutsdown. I did not want the service to shutdown.

This is a long stack trace, but is there a way to suppress
ServerImpl$ShutdownHook.run() sending the event to
org.apache.catalina.core.StandardContext.destroy()?

-------------------------------- This was the stack trace --------------
at org.apache.catalina.core.StandardWrapper.unload(StandardWrapper.java:1316)
at org.apache.catalina.core.StandardWrapper.stop(StandardWrapper.java:1651)
at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:892)
at org.apache.catalina.core.StandardContext.removeChild(StandardContext.java:3035)
at org.apache.catalina.startup.ContextConfig.stop(ContextConfig.java:1083)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:271)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4265)
at org.apache.catalina.core.ContainerBase.destroy(ContainerBase.java:1131)
at org.apache.catalina.core.StandardContext.destroy(StandardContext.java:4358)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:503)
at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:150)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.web.tomcat.tc5.TomcatDeployer.performUndeployInternal(TomcatDeployer.java:421)
at org.jboss.web.tomcat.tc5.TomcatDeployer.performUndeploy(TomcatDeployer.java:392)
at org.jboss.web.AbstractWebDeployer.stop(AbstractWebDeployer.java:404)
at org.jboss.web.WebModule.stopModule(WebModule.java:85)
at org.jboss.web.WebModule.stopService(WebModule.java:51)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStop(ServiceMBeanSupport.java:300)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:232)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:943)
at $Proxy0.stop(Unknown Source)
at org.jboss.system.ServiceController.stop(ServiceController.java:519)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
at $Proxy24.stop(Unknown Source)
at org.jboss.web.AbstractWebContainer.stop(AbstractWebContainer.java:432)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:118)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:80)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
at $Proxy25.stop(Unknown Source)
at org.jboss.deployment.MainDeployer.stop(MainDeployer.java:640)
at org.jboss.deployment.MainDeployer.stop(MainDeployer.java:632)
at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:613)
at org.jboss.deployment.MainDeployer.shutdown(MainDeployer.java:500)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:118)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.system.server.ServerImpl$ShutdownHook.shutdownDeployments(ServerImpl.java:988)
at org.jboss.system.server.ServerImpl$ShutdownHook.shutdown(ServerImpl.java:963)
at org.jboss.system.server.ServerImpl$ShutdownHook.run(ServerImpl.java:941)
------------------------------------------------------------------------------------


Thanks,
Vamsi

[peterj]

How did you install the service? Are you using JavaService or Java Service Wrapper? Also, why do you have to log in to start the service?

[vamsin]

we have our own Service installer which install couple more services and we specifically ignore this event for all these services:
CTRL_LOGOFF_EVENT from Windows Service Manager.

I can turn on the JVM option -Xrs to reduce the signals but within the JBoss console if I hit CTRL-C, it exits abruptly. We have a shutdown handler that does a graceful shutdown and is being ignored due to -Xrs option to jvm.

Is there any option that I can pass to Jboss to uninstall/ignore the event: CTRL_LOGOFF_EVENT?


-Regards
Vamsi

[peterj]

I do not think you have JBoss running as a service, but rather as a simple command line application. It is incredibly difficult to CTRL-C a service (it cannot be done unless you write some very complex C code). As long as it is running as a command line application, it will terminate when you log off.

[vamsin]

Thats correct, we have a service installer that takes 3 parameters (StartCmd, StopCmd, WorkingDir). You can provide any thing as start/stop command which in our case is an exe for a StartCmd and a batch file for a StopCmd.
In our exe, we have a console handler and realized by turning "Allow service to interact with Desktop" option. You can quit this exe by hitting CTRL-C in the console.


Vamsi

[peterj]

Like I said, I don't think you have a Windows service. Does anything show up for JBoss in the Services control panel? If not, it is not a service. In which case, when you log out, anything that was started, whether directly by you, or indirectly by some other application that you ran, will be terminated.

[vamsin]

It is a windows service. It shows up in the Services Panel.
I can start and I can stop. This service like I said, has a start command.
In my WindowsService Installer (c++ exe) program (much similar to JavaService.exe), I have a startProcess() which calls CreateProcess(...) to launch the "exe". This startProcess()'s handle is added to
void WINAPI ServiceMain(DWORD argc, LPSTR *argv)
{
gHandle= RegisterServiceCtrlHandlerA(g_szSvcName, SvcCtrlHandler);
startProcess(); // uses createProcess() to start an exe
}
where SvcCtrlHandler() listens to the following:
SERVICE_CONTROL_SHUTDOWN and
SERVICE_CONTROL_STOP
to handle stopService
This is probably what JavaService.exe does.


My **only** problem is when the user logs off the machine, the child process of my service: "myfoo.exe" exits, because it'sJVM received CTRL_LOGOFF_EVENT or an equivalent Signal from the OS that the JVM, started by JBoss, is registered to handle.

Vamsi

[peterj]

Are you using the Services Control Panel to start the service? Or running "net start jboss"? Is the service running under the system account or did you set up another account?

[vamsin]

Are you using the Services Control Panel to start the service?
>YES
Is the service running under the system account ?
> YES
It also has allow service to interact with desktop.
Do you know if there is a way to install a signal handler to intercept CTRL_LOGOFF_EVENT in jboss?
Are there any handlers that can be disabled to listen to CTRL_SHUTDOWN_EVENT or CTRL_LOGOFF_EVENT?
Is there anyway to alter the shutdown hook in JBoss?

[peterj]

Let me see if I understand this correctly. You service is launching another executable. You called it myfoo.exe. Did you write this executable also, or is this simply java.exe?

Snce Java is platform independent, it does not handle any Windows events. It does, however, handle signals such as SIG_INT, which jboss does handle by performing an orderly shutdown of the app server. If the executable that your service launches is one that you wrote, you can code it to handle Windows event.

The way JavaService works is that it uses JNI to load and execute the JVM, it does not fire up another executable to run the app server. In addition, JavaService handles the various Windows events.

[vamsin]

I fixed it like this:
--------------------------------------------------------------------------
1. create a JNI util dll for windows with one call:

BOOL WINAPI ConsoleCtrlHandler(DWORD dwCtrlType)
{
if (dwCtrlType == CTRL_LOGOFF_EVENT)
return TRUE; // ignore this signal and don't pass it on

return FALSE; // pass it on
}

JNIEXPORT void JNICALL Java_xxx_setConsoleCtrlHandler(JNIEnv *env, jclass jcl)
{
SetConsoleCtrlHandler(ConsoleCtrlHandler, TRUE);
return;
}
--------------------------------------------------------------------------
2. load this native library in my app's init()
2.a System.loadLibrary(name);
to do this: add -Djava.library.path option to your startup
2.b set the handler using the JNI call:
FOO.jniSetConsoleCtrlHandler();
--------------------------------------------------------------------------