Java wrapper error

#encoding=UTF-8
# Configuration files must begin with a line specifying the encoding
# of the the file.

….
#********************************************************************
# Wrapper Localization
#********************************************************************
# Specify the locale which the Wrapper should use. By default the system
# locale is used.
#wrapper.lang=en_US # en_US or ja_JP

# Specify the location of the Wrapper’s language resources. If these are
# missing, the Wrapper will default to the en_US locale.
wrapper.lang.folder=../lang

#********************************************************************
# Wrapper Java Properties
#********************************************************************
# Java Application
# Locate the java binary on the system PATH:
wrapper.java.command=java
# Specify a specific java binary:
#set.JAVA_HOME=/java/path
#wrapper.java.command=%JAVA_HOME%/bin/java

# Tell the Wrapper to log the full generated Java command line.
#wrapper.java.command.loglevel=INFO

# Java Main class. This class must implement the WrapperListener interface
# or guarantee that the WrapperManager class is initialized. Helper
# classes are provided to do this for you. See the Integration section
# of the documentation for details.
#wrapper.java.mainclass=org.tanukisoftware.wrapper.demo.DemoApp
wrapper.java.mainclass=COM.MainRunner

# Java Classpath (include wrapper.jar) Add class path elements as
# needed starting from 1
#wrapper.java.classpath.1=../lib/wrapperdemo.jar
wrapper.java.classpath.1=../lib/main.jar
#wrapper.java.classpath.2=../lib/wrapper.jar

# Java Library Path (location of Wrapper.DLL or libwrapper.so)
wrapper.java.library.path.1=../lib

# Java Bits. On applicable platforms, tells the JVM to run in 32 or 64-bit mode.
wrapper.java.additional.auto_bits=TRUE

# Java Additional Parameters
wrapper.java.additional.1=

# Initial Java Heap Size (in MB)
#wrapper.java.initmemory=3

# Maximum Java Heap Size (in MB)
#wrapper.java.maxmemory=64

# Application parameters. Add parameters as needed starting from 1
wrapper.app.parameter.1=»Oracle»

#********************************************************************
# Wrapper Logging Properties
#********************************************************************
# Enables Debug output from the Wrapper.
# wrapper.debug=TRUE

# Format of output for the console. (See docs for formats)
wrapper.console.format=PM

# Log Level for console output. (See docs for log levels)
wrapper.console.loglevel=INFO

# Log file to use for wrapper output logging.
wrapper.logfile=../logs/main.log

# Format of output for the log file. (See docs for formats)
wrapper.logfile.format=LPTM

# Log Level for log file output. (See docs for log levels)
wrapper.logfile.loglevel=INFO

# Maximum size that the log file will be allowed to grow to before
# the log is rolled. Size is specified in bytes. The default value
# of 0, disables log rolling. May abbreviate with the ‘k’ (kb) or
# ‘m’ (mb) suffix. For example: 10m = 10 megabytes.
wrapper.logfile.maxsize=0

# Maximum number of rolled log files which will be allowed before old
# files are deleted. The default value of 0 implies no limit.
wrapper.logfile.maxfiles=0

# Log Level for sys/event log output. (See docs for log levels)
wrapper.syslog.loglevel=NONE

#********************************************************************
# Wrapper General Properties
#********************************************************************
# Allow for the use of non-contiguous numbered properties
wrapper.ignore_sequence_gaps=TRUE

# Do not start if the pid file already exists.
wrapper.pidfile.strict=TRUE

# Title to use when running as a console
wrapper.console.title=Test Wrapper Sample Application

#********************************************************************
# Wrapper JVM Checks
#********************************************************************
# Detect DeadLocked Threads in the JVM. (Requires Standard Edition)
wrapper.check.deadlock=TRUE
wrapper.check.deadlock.interval=10
wrapper.max_failed_invocations=99
wrapper.console.fatal_to_stderr=FALSE
wrapper.console.error_to_stderr=FALSE
wrapper.check.deadlock.action=RESTART
wrapper.check.deadlock.output=FULL

# Out Of Memory detection.
# Ignore -verbose:class output to avoid false positives.
wrapper.filter.trigger.1000=[Loaded java.lang.OutOfMemoryError
wrapper.filter.action.1000=NONE
# (Simple match)
wrapper.filter.trigger.1001=java.lang.OutOfMemoryError
# (Only match text in stack traces if -XX:+PrintClassHistogram is being used.)
#wrapper.filter.trigger.1001=Exception in thread «*» java.lang.OutOfMemoryError
#wrapper.filter.allow_wildcards.1001=TRUE
wrapper.filter.action.1001=RESTART
wrapper.filter.message.1001=The JVM has run out of memory.

….
# Specify custom mail content
wrapper.event.jvm_restart.email.body=The JVM was restarted.nnPlease check on its status.n
….

1. Overview

ExecutorService is the central mechanism to execute tasks in Java. When we run our tasks in a thread pool backed by an ExecutorService, we must pay attention to exception handling. Remember that Java doesn’t require a method to handle or declare an unchecked RuntimeException, thus any code can throw a RuntimeException without us knowing. Upon getting an exception, we can log the error, notify a system, or take other diagnostic actions. In this tutorial, we’ll examine how we can handle exceptions thrown from the tasks running in an ExecutorService.

2. Default Behavior

If a thread terminates due to an uncaught exception, the JVM notifies the thread’s registered UncaughtExceptionHandler. If there is no registered handler, it prints the stack trace to System.err. 

public void executeThenThrowUnchecked() {
    final ExecutorService executorService = Executors.newFixedThreadPool(1);

    executorService.execute(() -> {
        System.out.println("I will throw RuntimeException now.");
        throw new RuntimeException("Planned exception after execute()");
    });

    executorService.shutdown();
}

Here, we’re first creating a thread pool by invoking newFixedThreadPool. Keep in mind that Executors.newFixedThread uses the DefaultThreadFactory class to create the worker threads. And DefaultThreadFactory doesn’t assign an UncaughtExceptionHandler to new threads. After we initialize the thread pool, we’re executing a Runnable task that throws a RuntimeException.

A sample run shows:

I will throw RuntimeException now.
Exception in thread "pool-1-thread-1" java.lang.RuntimeException: Planned exception after execute()
  at com.javabyexamples.java.concurrency.cancellation.exceptionhandling.DefaultBehavior.lambda$...
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
  at java.lang.Thread.run(Thread.java:748)

Here, the JVM prints the exception stack trace to the console, since the worker thread doesn’t have a registered UncaughtExceptionHandler.

2.1. Default Behavior with Callable

In the previous example, we’ve executed a Runnable task and the JDK tried to report the exception to a registered handler. However, if we submit a Callable task instead, ExecutorService returns a Future handle. The uncaught exception — if one occurs — is considered as a part of this Future. Thus the JDK doesn’t try to notify the handler:

public void submitThenThrowUnchecked() {
    final ExecutorService executorService = Executors.newFixedThreadPool(1);

    final Future<Object> futureHandle = executorService.submit(() -> {
        System.out.println("I will throw RuntimeException now.");
        throw new RuntimeException("Planned exception after submit()");
    });

    executorService.shutdown();
}

In this example, we’re submitting a Callable task instead of a Runnable. When we run the code, it doesn’t print the exception stack trace:

I will throw RuntimeException now.

We see the exception when we invoke the Future get method:

public void submitThenThrowUncheckedThenGet() {
    final ExecutorService executorService = Executors.newFixedThreadPool(1);
    final Future<Object> future = executorService.submit(() -> {
        System.out.println("I will throw RuntimeException now.");
        throw new RuntimeException("Planned exception after submit()");
    });

    try {
        future.get();
    } catch (InterruptedException e) {
        e.printStackTrace();
    } catch (ExecutionException e) {
        e.printStackTrace();
    }

    executorService.shutdown();
}

Here, when we invoke the get method, an ExecutionException will be thrown wrapping the original RuntimeException.

So we can conclude that even if a worker thread has an UncaughtExceptionHandler, the JDK won’t notify the handler for an uncaught exception that occurred in a Callable task.

3. Handle with UncaughtExceptionHandler

Next, we’ll register an UncaughtExceptionHandler to the worker threads. Remember that ExecutorService implementations use a ThreadFactory to create a new worker thread. For our purposes, we’ll create a new ThreadFactory implementation that sets an UncaughtExceptionHandler.

We’ll first define our handler:

public static class AppExceptionHandler implements UncaughtExceptionHandler {

    @Override
    public void uncaughtException(Thread t, Throwable e) {
        System.out.println("Uncaught Exception occurred on thread: " + t.getName());
        System.out.println("Exception message: " + e.getMessage());
    }
}

AppExceptionHandler simply logs the thread name and exception message.

Then we must implement a new ThreadFactory:

public static class AppThreadFactory implements ThreadFactory {

    @Override
    public Thread newThread(Runnable r) {
        final Thread thread = new Thread(r);
        thread.setUncaughtExceptionHandler(new AppExceptionHandler());
        return thread;
    }
}

AppThreadFactory sets a new AppExceptionHandler instance to every new thread invoking setUncaughtExceptionHandler.

Now that we have our thread factory, let’s use it when creating a thread pool:

public void executeThenThrowUnchecked() {
    final ExecutorService executorService = Executors.newFixedThreadPool(1, new AppThreadFactory());
    
    executorService.execute(() -> {
        System.out.println("I will throw RuntimeException now.");
        throw new RuntimeException("Planned exception after execute()");
    });

    executorService.shutdown();
}

We’re using the custom AppThreadFactory instead of DefaultThreadFactory. 

A sample run prints:

I will throw RuntimeException now.
Uncaught Exception occurred on thread: Thread-0
Exception message: Planned exception after execute()

There is no stack trace in the output since the thread has an assigned handler.

4. Handle with Wrapper Task

We’ll now investigate how we can handle an uncaught exception wrapping the original task. The previous UncaughtExceptionHandler approach applies to all threads and tasks in a thread pool. However, if we’re running different tasks in the same thread pool and they require different exception handling logic, this may not be optimal. Or we aren’t even allowed to set a handler because the task submission code is using a preconfigured pool. In these cases, we can wrap our original task in another Runnable or Callable. The wrapper class catches the exception and takes the appropriate action.

We’ll create a Runnable wrapper:

public static class CatchingRunnable implements Runnable {

    private final Runnable delegate;

    public CatchingRunnable(Runnable delegate) {
        this.delegate = delegate;
    }

    @Override
    public void run() {
        try {
            delegate.run();
        } catch (RuntimeException e) {
            System.out.println(e.getMessage()); // Log, notify etc...
            throw e;
        }
    }
}

CatchingRunnable contains a Runnable delegate. Notice the try/catch statement in the run method. If an exception occurs when running the delegate, we print the exception message. Though, this can be any other action to diagnose or notify the exception. Then we’re rethrowing the exception to not alter the original flow.

Let’s see the task submission code:

public void executeThenThrowUnchecked() {
    final ExecutorService executorService = Executors.newFixedThreadPool(1);
    final CatchingRunnable catchingRunnable = new CatchingRunnable(() -> {
        System.out.println("I will throw RuntimeException now.");
        throw new RuntimeException("Planned exception after execute()");
    });
    executorService.execute(catchingRunnable);

    executorService.shutdown();
}

Similar to the previous examples, we’re throwing a RuntimeException in our Runnable task.

When we run, it prints:

I will throw RuntimeException now.
Planned exception after execute()
Exception in thread "pool-1-thread-1" java.lang.RuntimeException: Planned exception after execute()
  at com.javabyexamples.java.concurrency.cancellation.exceptionhandling.WithWrappingTask.lambda$...
  at com.javabyexamples.java.concurrency.cancellation.exceptionhandling.WithWrappingTask$CatchingRunnable.run...
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
  at java.lang.Thread.run(Thread.java:748)

In the output, we see lines from multiple parts of the code. The first line comes from the original Runnable task. Then CatchingRunnable prints the exception message. Lastly, the JDK prints the stack trace since there is no registered UncaughtExceptionHandler.

5. Handle with Overriding afterExecute

Lastly, we’ll extend the ThreadPoolExecutor class to handle the uncaught exceptions. For this purpose, we’ll use the afterExecute hook method that ThreadPoolExecutor provides:

protected void afterExecute(Runnable r, Throwable t) { }

If the task completes normally, the Throwable argument is null. Otherwise, it contains the exception that caused the termination.

Now, we’ll extend ThreadPoolExecutor:

public static class MonitoringThreadPoolExecutor extends ThreadPoolExecutor {

    public MonitoringThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit,
      BlockingQueue<Runnable> workQueue) {
        super(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue);
    }

    @Override
    protected void afterExecute(Runnable r, Throwable t) {
        super.afterExecute(r, t);
        if(t != null){
            System.out.println("Exception message: " + t.getMessage());    
        }
    }
}

Here, we have the MonitoringThreadPoolExecutor class. In the afterExecute method, we print the exception message if one occurs.

Next, instead of using Executors, we’ll directly instantiate the thread pool:

public void executeThenThrowUnchecked() {
    final ExecutorService executorService = new MonitoringThreadPoolExecutor(1, 1, 0, TimeUnit.SECONDS,
      new LinkedBlockingQueue<>());
    executorService.execute(() -> {
        System.out.println("I will throw RuntimeException now.");
        throw new RuntimeException("Planned exception after execute()");
    });

    executorService.shutdown();
}

A sample run prints:

I will throw RuntimeException now.
Exception message: Planned exception after execute()
Exception in thread "pool-1-thread-1" java.lang.RuntimeException: Planned exception after execute()
  at com.javabyexamples.java.concurrency.cancellation.exceptionhandling.WithOverridingAfterExecute.lambda$...
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
  at java.lang.Thread.run(Thread.java:748)

6. Summary

In this tutorial, we investigate how to handle an exception for tasks running in a thread pool. We first looked at the default exception handling behavior and the UncaughtExceptionHandler interface. Then we examined the wrapper tasks for more control on the handling logic. Then we extended the ThreadPoolExecutor class as a more general approach.

Lastly, check out the source code for all examples over on Github.

My application runs when run in command prompt
java -cp «resources;GlobasysLogger.jar» -Djava.library.path=lib com.globasyslogger.startup.StartGLogger

Above command works perfectly (It also has some dll )

When the same configured with wrapper, with following configuration

################################################
wrapper.java.command=java.exe

wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp

# Java Classpath (include wrapper.jar) Add class path elements as
wrapper.java.classpath.1=../lib/wrapper.jar
wrapper.java.classpath.2=../../resources
wrapper.java.classpath.3=../../lib
wrapper.java.classpath.4=../../GlobasysLogger.jar

# Java Library Path (location of Wrapper.DLL or libwrapper.so)
wrapper.java.library.path.1=../lib
wrapper.java.library.path.2=../../lib

# Application parameters. Add parameters as needed starting from 1
wrapper.app.parameter.1=com.globasyslogger.startup.StartGLogger

wrapper.ntservice.account=.Administrator
wrapper.ntservice.password=123123
wrapper.debug=true
##################################################

when i run the command
wrapper.exe -c ..confwrapper.conf

It gives following log

#################################################
wrapper | —> Wrapper Started as Console
wrapper | Java Service Wrapper Community Edition 3.3.0
wrapper | Copyright (C) 1999-2008 Tanuki Software, Inc. All Rights Reserved.

wrapper | http://wrapper.tanukisoftware.org
wrapper |
wrapper | Using tick timer.
wrapperp | server listening on port 32000.
wrapper | Ping settings: wrapper.ping.interval=5, wrapper.ping.interval.logged=
1, wrapper.ping.timeout=30
wrapper | Launching a JVM…
wrapper | command: «D:Program FilesJavajre1.6.0binjava.exe» -Djava.library
.path=»../lib;../../lib» -classpath «../lib/wrapper.jar;../../resources;../../li
b;../../GlobasysLogger.jar» -Dwrapper.key=»oQ78ujCGsmQnJYkE» -Dwrapper.port=3200
0 -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999 -Dwrapper.debug=»TRU
E» -Dwrapper.pid=2400 -Dwrapper.version=»3.3.0″ -Dwrapper.native_library=»wrappe
r» -Dwrapper.cpu.timeout=»10″ -Dwrapper.jvmid=1 org.tanukisoftware.wrapper.Wrapp
erSimpleApp com.globasyslogger.startup.StartGLogger
wrapper | JVM started (PID=6676)
jvm 1 | WrapperManager Debug: WrapperManager class initialized by thread: mai
n Using classloader: sun.misc.Launcher$AppClassLoader@11b86e7
jvm 1 | WrapperManager: Initializing…
jvm 1 | WrapperManager Debug: JVM #1
jvm 1 | WrapperManager Debug: Running a 32-bit JVM.
jvm 1 | WrapperManager Debug: Registering shutdown hook
jvm 1 | WrapperManager Debug: Using wrapper
jvm 1 | WrapperManager Debug: Load native library. One or more attempts may
fail if platform specific libraries do not exist. This is NORMAL and is only a
problem if they all fail.
jvm 1 | WrapperManager Debug: Loaded native library: wrapper-windows-x86-32
.dll
jvm 1 | WrapperManager Debug: Calling native initialization method.
jvm 1 | WrapperJNI Debug: Initializing WrapperManager native library.
jvm 1 | WrapperJNI Debug: Java Executable: D:Program FilesJavajre1.6.0bin
java.exe
jvm 1 | WrapperJNI Debug: Windows version: 5.1.2600
jvm 1 | WrapperManager Debug: Java Version : 1.6.0-b105 Java HotSpot(TM) Cl
ient VM
jvm 1 | WrapperManager Debug: Java VM Vendor : Sun Microsystems Inc.
jvm 1 | WrapperManager Debug:
jvm 1 | WrapperManager Debug: Control event monitor thread started.
jvm 1 | WrapperManager Debug: Startup runner thread started.
jvm 1 | WrapperManager Debug: WrapperManager.start(org.tanukisoftware.wrapper
.WrapperSimpleApp@bb6ab6, args[]) called by thread: main
jvm 1 | WrapperManager Debug: Communications runner thread started.
jvm 1 | WrapperManager Debug: Open socket to wrapper…Wrapper-Connection
jvm 1 | WrapperManager Debug: Opened Socket from 31000 to 32000
jvm 1 | WrapperManager Debug: Send a packet KEY : oQ78ujCGsmQnJYkE
jvm 1 | WrapperManager Debug: handleSocket(Socket[addr=/127.0.0.1,port=32000,
localport=31000])
wrapperp | accepted a socket from 127.0.0.1 on port 31000
wrapperp | read a packet KEY : oQ78ujCGsmQnJYkE
wrapper | Got key from JVM: oQ78ujCGsmQnJYkE
wrapperp | send a packet LOW_LOG_LEVEL : 1
wrapperp | send a packet PING_TIMEOUT : 30
wrapperp | send a packet PROPERTIES : (Property Values)
wrapper | Start Application.
wrapperp | send a packet START : start
jvm 1 | WrapperManager Debug: Received a packet LOW_LOG_LEVEL : 1
jvm 1 | WrapperManager Debug: LowLogLevel from Wrapper is 1
jvm 1 | WrapperManager Debug: Received a packet PING_TIMEOUT : 30
jvm 1 | WrapperManager Debug: PingTimeout from Wrapper is 30000
jvm 1 | WrapperManager Debug: Received a packet PROPERTIES : (Property Values
)
jvm 1 | WrapperManager Debug: Received a packet START : start
jvm 1 | WrapperManager Debug: calling WrapperListener.start()
jvm 1 | WrapperManager Debug: Waiting for WrapperListener.start runner thread
to complete.
jvm 1 | WrapperManager Debug: WrapperListener.start runner thread started.
jvm 1 | WrapperSimpleApp Debug: start(args) Will wait up to 2 seconds for the
main method to complete.
jvm 1 | WrapperSimpleApp Debug: invoking main method
jvm 1 | WrapperManager Debug: Send a packet START_PENDING : 5000
wrapperp | read a packet START_PENDING : 5000
wrapper | JVM signalled a start pending with waitHint of 5000 millis.
jvm 1 | WrapperManager Debug: Send a packet START_PENDING : 5000
jvm 1 | WrapperSimpleApp Debug: start(args) end. Main Completed=false, exitC
ode=null
jvm 1 | WrapperManager Debug: WrapperListener.start runner thread stopped.
jvm 1 | WrapperManager Debug: returned from WrapperListener.start()
jvm 1 | WrapperManager Debug: Send a packet STARTED :
wrapperp | read a packet START_PENDING : 5000
wrapper | JVM signalled a start pending with waitHint of 5000 millis.
wrapperp | read a packet STARTED :
wrapper | JVM signalled that it was started.
jvm 1 | WrapperManager Debug: Startup runner thread stopped.
wrapperp | send a packet PING : ping
jvm 1 | WrapperManager Debug: Received a packet PING : ping
jvm 1 | WrapperManager Debug: Send a packet PING : ping
wrapperp | read a packet PING : ping
jvm 1 | WrapperSimpleApp Debug: main method completed
jvm 1 | [thread 7196 also had an error]
jvm 1 | #
jvm 1 | # An unexpected error has been detected by Java Runtime Environment:
jvm 1 | #
jvm 1 | # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x77ea4d3a, pid=6676
, tid=4196
jvm 1 | #
jvm 1 | # Java VM: Java HotSpot(TM) Client VM (1.6.0-b105 mixed mode, sharing
)
jvm 1 | # Problematic frame:
jvm 1 | # C [RPCRT4.dll+0x34d3a]
jvm 1 | #
jvm 1 | # An error report file with more information is saved as hs_err_pid66
76.log
jvm 1 | #
jvm 1 | # If you would like to submit a bug report, please visit:
jvm 1 | # http://java.sun.com/webapps/bugreport/crash.jsp
jvm 1 | #
wrapper | JVM process exited with a code of 1, setting the wrapper exit code to
1.
wrapper | JVM exited unexpectedly.
wrapperp | server listening on port 32000.
wrapper | JVM was only running for 6 seconds leading to a failed restart count
of 1.
wrapper | Waiting 5 seconds before launching another JVM.
wrapper | CTRL-C trapped. Shutting down.
wrapper | wrapperStopProcess(0) called.
wrapper | <— Wrapper Stopped

###################################################

I have also attached the pid file