It's possible to disable shutdown hooks in log4j2 via configuration:
<Configuration shutdownHook="disable">
Is it possible to do so programmatically?
I know, it's probably outdated but I felt on your question and I was in the same situation. So for people interested, I use this piece of code to stop the shutdown hook programmaticaly :
final LoggerContextFactory factory = LogManager.getFactory();
if (factory instanceof Log4jContextFactory) {
LOG.info("register shutdown hook");
Log4jContextFactory contextFactory = (Log4jContextFactory) factory;
((DefaultShutdownCallbackRegistry) contextFactory.getShutdownCallbackRegistry()).stop();
}
and in my own shutdown hook
LogManager.shutdown();
log4j2: 2.8.2 (but should be available since 2.6)
Related
I was trying to find out what is the right way to stop a RabbitMQ applicaton safely if it is interrupted by interrupts like Ctrl-C or a normal shutdown
Is it enough I have an ApplicationContext.close ( with a registered hook ) which will implicitly take care about complete graceful shutdown from ConnectionFactory to Listeneres ?
I tried to implement destroy for only listeners as mentioned in some blogs
when I have a configuration like
<rabbit:listener-container connection-factory="connectionFactory" >
<rabbit:listener id = "X" ref="onMessageX" queue-names="Z" />
<rabbit:listener id = "A" ref="onMessageB" queue-names="A" />
<rabbit:listener id= "C" ref="onMessageC" queue-names="C" />
</rabbit:listener-container>
and when I tried
SimpleMessageListenerContainer Container = context.getBean(SimpleMessageListenerContainer.class);
I ended up getting 3 Container beans when I expected one , each listener became a container.
I was able to close each using stop after getting using getBeansOfType into MAP and iterating. Shutdown happens if you keep it in destroy and applicationContext.close happens.
Am I trying to do something too complicated and stupid here ? What and all need to be stopped if we need to start stopping from connection factory.
Your observation about <rabbit:listener-container> is fully correct. You have target MessageListenerContainers as many as you specify <rabbit:listener> sub-elements there.
When Ctrl-C happens, the normal ApplicationContext.close() should do the work for your to stop all the containers gracefully.
I am making use of the <jmxConfigurator/> element in logback; The jmxConfigurator states the following:
Thus, unless your application is a standalone Java application, you **MUST** unregister the JMXConfigurator instance from the JVM's Mbeans server.
The logback documentation also mentions a <shutdownHook/> configuration element which according to the documentation does the following:
Installing a JVM shutdown hook is a convenient way for shutting down logback and releasing associated resources.
Does including the <shutdownHook/> element take care of unregistering the <jmxConfigurator/>?
Yes, it does. Here is a proof from the debugger:
However, there are a few restrictions:
<shutdownHook/> is available only as of version 1.1.3
although the documentation says that plain <shutdownHook/> is enough, you have to specify the class property:
<shutdownHook class="ch.qos.logback.core.hook.DelayingShutdownHook"/>
otherwise logback complains with:
ERROR in ch.qos.logback.core.joran.action.ShutdownHookAction - Missing class name for shutdown hook. Near [shutdownHook] line 16
To make sure that the JMXConfigurator gets stopped enable debug mode on the logback configuration:
<configuration debug="true">
...
</configuration>
Then at the end of your logs you'll see:
INFO in ch.qos.logback.core.hook.DelayingShutdownHook#1a246fc6 - Logback context being closed via shutdown hook
INFO in ch.qos.logback.classic.jmx.JMXConfigurator(default) - onReset() method called JMXActivator [ch.qos.logback.classic:Name=default,Type=ch.qos.logback.classic.jmx.JMXConfigurator]
Environment: Grails 2.0.3, Quartz plugin 1.0-RC2
I have a simple quartz job that reads a value from the database. On the 8th execution, the Job freezes while reading from the database. There is also a web page that retrieves the value from the DB. Once the Job gets into the waiting state, attempting to read the value through the web page also freezes.
Environment: Grails 2.2.0, Quartz plugin 1.0-RC5
I ran into the same problem using quartz-1.0-RC5.
As a workaround I replaced the SessionBinderJobListener class with the one from quartz-0.4.2 (changed only the package to the new one) and the job runs again without any problem. So it looks like the persistenceInterceptor bean does not close the connections or return them to the pool. Maybe there is a problem in org.codehaus.groovy.grails.orm.hibernate.support.HibernatePersistenceContextInterceptor with flush and destroy.
If org.quartz.threadPool.threadCount is much less than maxActive in dataSource properties, the problem does not appear (perhaps each job thread already got its connection) or it will only take longer.
The default size of the datasource connection pool is 8, so you're probably not properly closing the connections to return them to the pool.
I'm seeing the same thing with Quartz plugin version 1.0.1. On the 8th execution both the Job and Tomcat workers freeze. Used withSession and called Hibernate session.disconnect() in the finally {} block of the job. That did the trick.
def execute() {
def hsession
try {
DomainObject.withSession { ses ->
hsession = ses
....
}
} catch(Exception e) {
//log it etc.
} finally {
hsession?.disconnect()
}
}
I've implemented quartz.net in windows service to run tasks. And everything works fine on local workstation. But once it's deployed to remote win server host, it just hangs after initialization.
ISchedulerFactory schedFact = new StdSchedulerFactory();
// get a scheduler
var _scheduler = schedFact.GetScheduler();
// Configuration of triggers and jobs
var trigger = (ICronTrigger)TriggerBuilder.Create()
.WithIdentity("trigger1", "group1")
.WithCronSchedule(job.Value)
.Build();
var jobDetail = JobBuilder.Create(Type.GetType(job.Key)).StoreDurably(true)
.WithIdentity("job1", "group1").Build();
var ft = _scheduler.ScheduleJob(jobDetail, trigger);
Everything seems to be standard. I have private static pointer to scheduler, logging process stops right after jobs are initialized and added to scheduler. Nothing else happens after.
I'd appreciate any advices.
Thanks.
PS:
Found some strange events in event viewer mb according quartz.net:
Restart Manager - Starting session 2 - 2012-07-09T15:14:15.729569700Z.
Restart Manager - Ending session 2 started 2012-07-09T15:14:15.729569700Z.
Based on your question and the additional info you gave in comments, I would guess there is something going wrong in the onStart method of your service.
Here are some things you can do to help figure out and solve the problem:
Place the code in your onStart method in a try/catch block, and try to install and start the service. Then check windows logs to see if it was installed correctly, started correctly, etc.
The fact that restart manager is running leads me to believe that your service may be dependent on a process which is already in use. Make sure that any dependencies of your service are closed before installing it.
This problem can also be caused by putting data-intense or long running operations in your onStart method. Make sure that you keep this kind of code out of onStart.
I had a similar problem to this and it was caused by having dots/periods in the assembly name e.g. Project.Update.Service. When I changed it to ProjectUpdateService it worked fine.
Strangely it always worked on the development machine. Just never on the remote machine.
UPDATE: It may have been the length of the service that has caused this issue. By removing the dots I shortened the service name. It looks like the maximum length is 25 characters.
I'm trying to stop a Windows service on a local machine (the service is Topshelf.Host, if that matters) with this code:
serviceController.Stop();
serviceController.WaitForStatus(ServiceControllerStatus.Stopped, timeout);
timeout is set to 1 hour, but service never actually gets stopped. Strange thing with it is that from within Services MMC snap-in I see it in "Stopping" state first, but after a while it reverts back to "Started". However, when I try to stop it manually, an error occurs:
Windows could not stop the Topshelf.Host service on Local Computer.
Error 1061: The service cannot accept control messages at this time.
Am I missing something here?
I know I am quite late to answer this but I faced a similar issue , i.e., the error: "The service cannot accept control messages at this time." and would like to add this as a reference for others.
You can try killing this service using powershell (run powershell as administrator):
#Get the PID of the required service with the help of the service name, say, service name.
$ServicePID = (get-wmiobject win32_service | where { $_.name -eq 'service name'}).processID
#Now with this PID, you can kill the service
taskkill /f /pid $ServicePID
Either your service is busy processing some big operation or is in transition to change the state. hence is not able to accept anymore input...just think of it as taking more than it can chew...
if you are sure that you haven't fed anything big to it, just go to task manager and kill the process for this service or restart your machine.
I had exact same problem with Topshelf hosted service. Cause was long service start time, more than 20 seconds. This left service in state where it was unable to process further requests.
I was able to reproduce problem only when service was started from command line (net start my_service).
Proper initialization for Topshelf service with long star time is following:
namespace Example.My.Service
{
using System;
using System.Threading.Tasks;
using Topshelf;
internal class Program
{
public static void Main()
{
HostFactory.Run(
x =>
{
x.Service<MyService>(
s =>
{
MyService testServerService = null;
s.ConstructUsing(name => testServerService = new MyService());
s.WhenStarted(service => service.Start());
s.WhenStopped(service => service.Stop());
s.AfterStartingService(
context =>
{
if (testServerService == null)
{
throw new InvalidOperationException("Service not created yet.");
}
testServerService.AfterStart(context);
});
});
x.SetServiceName("my_service");
});
}
}
public sealed class MyService
{
private Task starting;
public void Start()
{
this.starting = Task.Run(() => InitializeService());
}
private void InitializeService()
{
// TODO: Provide service initialization code.
}
[CLSCompliant(false)]
public void AfterStart(HostControl hostStartedContext)
{
if (hostStartedContext == null)
{
throw new ArgumentNullException(nameof(hostStartedContext));
}
if (this.starting == null)
{
throw new InvalidOperationException("Service start was not initiated.");
}
while (!this.starting.Wait(TimeSpan.FromSeconds(7)))
{
hostStartedContext.RequestAdditionalTime(TimeSpan.FromSeconds(10));
}
}
public void Stop()
{
// TODO: Provide service shutdown code.
}
}
}
I've seen this issue as well, specifically when a service is start pending and I send it a stop programmatically which succeeds but does nothing. Also sometimes I see stop commands to a running service fail with this same exception but then still actually stop the service. I don't think the API can be trusted to do what it says. This error message explanation is quite helpful...
http://technet.microsoft.com/en-us/library/cc962384.aspx
I run into a similar issue and found out it was due to one of the services getting stuck in a state of start-pending, stop pending, or stopped.
Rebooting the server or trying to restart services did not work.
To solve this, I run the Task Manager in the server and in the "Details" tab I located the services that were stuck and killed the process by ending the task. After ending the task I was able to restart services without problem.
In brief:
1. Go to Task Manager
2. Click on "Detail" tab
3. Locate your service
4. Right click on it and stop/kill the process.
That is it.
I know it was opened while ago, but i am bit missing the option with Windows command prompt, so only for sake of completeness
Open Task Manager and find respective process and its PID i.e PID = 111
Eventually you can narrow down the executive file i.e. Image name = notepad.exe
in command prompt use command TASKKILL
example: TASKKILL /F /PID 111 ; TASKKILL /F /IM notepad.exe
I had this exact issue internally when starting and stopping a service using PowerShell (Via Octopus Deploy). The root cause for the service not responding to messages appeared to be related to devs accessing files/folders within the root service install directory via an SMB connection (looking at a config file with notepad/explorer).
If the service gets stuck in that situation then the only option is to kill it and sever the connections using computer management. After that, service was able to be redeployed fine.
May not be the exact root cause, but something we now check for.
I faced the similar issue. This error sometimes occur because the service can no longer accept control messages, this may be due to disk space issues in the server where that particular service's log file is present.
If this occurs, you can consider the below option as well.
Go to the location where the service exe & its log file is located.
Free up some space
Kill the service's process via Task manager
Start the service.
I just fought this problem while moving code from an old multi partition box to a newer single partition box. On service stop I was writing to D: and since it didn't exist anymore I got a 1061 error. Any long operation during the OnStop will cause this though unless you spin the call off to another thread with a callback delegate.