We Keep Coding

How to get the actual start time of the service using ManagementFactory.getRuntimeMXBean().getStartTime()

I have to implement a logic based on the JVM StartTime. How may I get the actual start time of the JVM? Even the JVM restarts internally also can I able to use this ManagementFactory.getRuntimeMXBean().getStartTime() method?
Below is the sample of logs of the service which I run in my environment.
I have started the windows service # 01/01/2022 10:00:00 by which the code is created using Java. By the time the wrapper service prints the logs like below,
STATUS | wrapper | 2022/01/01 10:00:00 | Launching a JVM...
INFO | jvm 1 | 2022/01/01 10:00:00 | WrapperManager: Initializing...
INFO | jvm 1 | 2022/01/01 10:00:00 | Wrapper startup method..
After some period of time wrapper service prints, the logs like JVM is restarting and the new JVM to be launch,
STATUS | wrapper | 2022/01/01 10:58:01 | JVM requested a restart.
INFO | jvm 1 | 2022/01/01 10:58:02 | Going to shutdown the all threads...0
STATUS | wrapper | 2022/01/01 10:58:09 | Launching a JVM...
INFO | jvm 2 | 2022/01/01 10:58:09 | WrapperManager: Initializing...
INFO | jvm 2 | 2022/01/01 10:58:09 | Wrapper startup method..
What the doubt is even if the JVM is launching again internally without restarting the service manually will this ManagementFactory.getRuntimeMXBean().getStartTime() method returns the start time as 01/01/2022 10:00:00???
Someone help me in this context to find the actual start time of the service.

null pointer in java NIO SSO processor

trying to run gitblit, on tomcat 9, using JDK 11 occassionaly results in this stack trace:
gitblit | 07-May-2020 04:30:39.247 SEVERE [https-jsse-nio-8443-exec-10] org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun Error running socket processor
gitblit | java.lang.NullPointerException
gitblit | at java.base/sun.security.ssl.HKDF.extract(HKDF.java:93)
gitblit | at java.base/sun.security.ssl.HKDF.extract(HKDF.java:119)
gitblit | at java.base/sun.security.ssl.ServerHello.setUpPskKD(ServerHello.java:1167)
gitblit | at java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:545)
gitblit | at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436)
gitblit | at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1234)
gitblit | at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1170)
gitblit | at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:852)
gitblit | at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813)
gitblit | at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
gitblit | at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
gitblit | at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061)
gitblit | at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1048)
gitblit | at java.base/java.security.AccessController.doPrivileged(Native Method)
gitblit | at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:995)
gitblit | at org.apache.tomcat.util.net.SecureNioChannel.tasks(SecureNioChannel.java:443)
gitblit | at org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap(SecureNioChannel.java:507)
gitblit | at org.apache.tomcat.util.net.SecureNioChannel.handshake(SecureNioChannel.java:238)
gitblit | at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1616)
gitblit | at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
gitblit | at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
gitblit | at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
gitblit | at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
gitblit | at java.base/java.lang.Thread.run(Thread.java:834)
When the clients are trying to pull files from the gitblit GUI.
Possibly of interest, until I updated to the 11.0.7 version of the JDF, I was seeing this error:
Open JDK 11 HTTP/2 Handshake ServerHello java.util.NoSuchElementException
Where the fixed the mis-use of the Optional here: https://bugs.openjdk.java.net/browse/JDK-8218889 but perhaps, didn't actually address the root problem?
Or any other thoughts as to what is triggering this error? I'm using a self-signed cert here, FYI. The client is Firefox, and the java release is
openjdk version "11.0.7" 2020-04-14
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.7+10)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.7+10, mixed mode)
Running inside an alpine linux docker system.
Chasing down an issue where gitblit has occassional 1 minute timeouts, and finding this in the log. Not sure if related, or not....
Looks like it has also been found in tomcat https://bz.apache.org/bugzilla/show_bug.cgi?id=64105, and reported here
https://bugs.openjdk.java.net/browse/JDK-8241248
Since I can't provide info on the openjdk bug tracker, I can tell you that the client that typically causes it for me is Firefox 75 on linux.

As pointed out by the bugtracker references that you provide, this is a bug related to session resumption.
While this answer does not address the bug itself, there is a possibility to ask the SSLEngine to disallow resumption for a particular connection. This comes at a performance penalty for future connections because the client is required to redo the handshake for new connections instead of leveraging the session resumption mechanism.
At any time after the handshake is established, you can call invalidate() on the SSLSession. As pointed in the doc:
Future connections will not be able to resume or join this session. However, any existing connection using this session can continue to use the session until the connection is closed.
Meaning that it has no effect on the current connection, but will prevent session resumption and thus avoid the JDK bug.
My snippet for the handshake loop:
case NOT_HANDSHAKING:
case FINISHED:
{
if( !sslEngine.getSession().isValid() || sslEngine.getSession().getId().length == 0 )
throw new SSLHandshakeException("Handshake failed");
// prevent bug with rejoin session
sslEngine.getSession().invalidate();
return;
}

Channel closed when running simple example with TLS

I'm trying to run the official "Hello, World" example with TLS, provided by the gRPC team (code on GitHub).
I've cloned the official repo and checked out tag v1.15.0.
I've run the installation script as follows (as shown in the documentation):
./gradlew installDist
I've edited the launch scripts for hello-world-server and hello-world-client to run the classes io.grpc.examples.helloworldtls.HelloWorldServerTls and io.grpc.examples.helloworldtls.HelloWorldClientTls respectively.
I've created the certificates needed for the TLS authentication to happen using the script provided as part of the documentation and stored them in a directory I named cert.
Finally, I've run the server as follows:
./build/install/examples/bin/hello-world-server localhost 50440 cert/server.crt cert/server.pem
The server starts correctly and outputs the following:
Oct 08, 2018 9:15:10 AM io.grpc.examples.helloworldtls.HelloWorldServerTls start
INFO: Server started, listening on 50440
Finally, I try to start the client on another shell with the following command:
./build/install/examples/bin/hello-world-client localhost 50440 cert/ca.crt
Unfortunately, the client fails with the following output:
Oct 08, 2018 9:25:22 AM io.grpc.examples.helloworldtls.HelloWorldClientTls greet
INFO: Will try to greet localhost ...
Oct 08, 2018 9:25:22 AM io.grpc.examples.helloworldtls.HelloWorldClientTls greet
WARNING: RPC failed: Status{code=UNKNOWN, description=channel closed, cause=java.nio.channels.ClosedChannelException
at io.grpc.netty.Utils.statusFromThrowable(Utils.java:169)
at io.grpc.netty.NettyClientTransport$5.operationComplete(NettyClientTransport.java:260)
at io.grpc.netty.NettyClientTransport$5.operationComplete(NettyClientTransport.java:254)
at io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:511)
at io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:485)
at io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:424)
at io.netty.util.concurrent.DefaultPromise.setFailure(DefaultPromise.java:112)
at io.netty.channel.DefaultChannelPromise.setFailure(DefaultChannelPromise.java:89)
at io.grpc.netty.ProtocolNegotiators$AbstractBufferingHandler.fail(ProtocolNegotiators.java:564)
at io.grpc.netty.ProtocolNegotiators$BufferUntilTlsNegotiatedHandler.userEventTriggered(ProtocolNegotiators.java:661)
at io.netty.channel.AbstractChannelHandlerContext.invokeUserEventTriggered(AbstractChannelHandlerContext.java:329)
at io.netty.channel.AbstractChannelHandlerContext.invokeUserEventTriggered(AbstractChannelHandlerContext.java:315)
at io.netty.channel.AbstractChannelHandlerContext.fireUserEventTriggered(AbstractChannelHandlerContext.java:307)
at io.netty.handler.ssl.SslUtils.handleHandshakeFailure(SslUtils.java:318)
at io.netty.handler.ssl.SslHandler.setHandshakeFailure(SslHandler.java:1551)
at io.netty.handler.ssl.SslHandler.channelInactive(SslHandler.java:1023)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:245)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:231)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:224)
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelInactive(DefaultChannelPipeline.java:1429)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:245)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:231)
at io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:947)
at io.netty.channel.AbstractChannel$AbstractUnsafe$8.run(AbstractChannel.java:822)
at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:404)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:464)
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:884)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.nio.channels.ClosedChannelException
at io.netty.handler.ssl.SslHandler.channelInactive(...)(Unknown Source)
}
The error occurs with mutual authentication as well.
I'm not sure what's going wrong or how to find the root cause of this, do you have any pointers?

As it turns out, I was using incompatible versions of gRPC and BoringSSL.
The "Troubleshooting" section of this document contains a table with known compatible versions of the library.
The following is a table with known compatible versions as of October 2018:
grpc-netty version | netty-handler version | netty-tcnative-boringssl-static version
------------------ | --------------------- | ---------------------------------------
1.0.0-1.0.1 | 4.1.3.Final | 1.1.33.Fork19
1.0.2-1.0.3 | 4.1.6.Final | 1.1.33.Fork23
1.1.x-1.3.x | 4.1.8.Final | 1.1.33.Fork26
1.4.x | 4.1.11.Final | 2.0.1.Final
1.5.x | 4.1.12.Final | 2.0.5.Final
1.6.x | 4.1.14.Final | 2.0.5.Final
1.7.x-1.8.x | 4.1.16.Final | 2.0.6.Final
1.9.x-1.10.x | 4.1.17.Final | 2.0.7.Final
1.11.x-1.12.x | 4.1.22.Final | 2.0.7.Final
1.13.x | 4.1.25.Final | 2.0.8.Final
1.14.x- | 4.1.27.Final | 2.0.12.Final

Fuse ESB mysteriously hangs - "JVM appears hung: Timed out waiting for signal from JVM."

My Fuse ESB application suddenly stopped, with no clues in fuseesb.log and the following weird log items in wrapper.log:
ERROR | wrapper | 2014/02/12 02:36:59 | JVM appears hung: Timed out waiting for signal from JVM.
ERROR | wrapper | 2014/02/12 02:36:59 | JVM did not exit on request, terminated
STATUS | wrapper | 2014/02/12 02:37:02 | JVM exited in response to signal SIGKILL (9).
ERROR | wrapper | 2014/02/12 02:37:02 | Unable to start a JVM
STATUS | wrapper | 2014/02/12 02:37:02 | <-- Wrapper Stopped
We are using Nagios to monitor the system.
System info: FuseESBEnterprise-7.1.0 / linux-gnu (x86_64).
For various reasons we need to sick with Fuse ESB (not possible to migrate to JBoss Fuse...)

This was a system issue - the vm hung.
You can catch this kind of condition in one of two ways:
monitor the java jvm process
monitor the wrapper.log file for errors

java service wrapper, very basic step by step setup with startup failure

I have simply donwloaded JSW community edition, unwrapped into a directory:
c:\servicetest
So here i have a bin, conf, lib and log subdirs, among others.
From now on this will be (root).
I referenced the (root)/lib/wrapper.jar into my ide (netbeans) and create a very simple service (remember the class name is Main):
public class Main extends WrapperSimpleApp {
public Main(String[] args) {
super(args);
}
#Override
public void run() {
while(true) {
Logger.getLogger(Main.class.getName()).log(Level.INFO, "I'm alive");
try
{ Thread.sleep(2000); }
catch (InterruptedException ex)
{ return; }
}
}
}
As you see, it basically does nothing but logging a message. But actually it neither starts.
I compiled the project (MyProject.jar), copied the jar into the (root) directory and modified the (root)/config/wrapper.conf adding:
wrapper.java.classpath.3=../MyProject.jar
and
wrapper.java.mainclass=textappender.Main
Then i've installed the service in command line, with:
C:\servicetest\bin>wrapper -i ../conf/wrapper.conf
then i've started the service, either via services.msc control panel or via
C:\servicetest\bin>wrapper -t ../conf/wrapper.conf
In logs/wrapper.log i get:
ERROR | wrapper | 2012/05/21 21:35:11 | JVM exited while loading the application.
UPDATE 1
Following Tanuki Software advice, i've set in my (root)/config/wrapper.conf (well, uncommented since it already was):
wrapper.debug=TRUE
And now i get this:
INFO | jvm 1 | 2012/05/22 10:46:37 | WrapperManager Debug: WrapperManager.stop(1) called by thread: main
INFO | jvm 1 | 2012/05/22 10:46:37 | WrapperManager Debug: Backend not connected, not sending packet STOP : 1
INFO | jvm 1 | 2012/05/22 10:46:37 | WrapperManager Debug: Stopped checking for control events.
DEBUG | wrapper | 2012/05/22 10:46:37 | Pause reading child process output to share cycles.
INFO | jvm 1 | 2012/05/22 10:46:37 | WrapperManager Debug: Thread, main, handling the shutdown process.
INFO | jvm 1 | 2012/05/22 10:46:37 | WrapperManager Debug: shutdownJVM(1) Thread: main
INFO | jvm 1 | 2012/05/22 10:46:38 | WrapperManager Debug: wait for 0 shutdown locks to be released.
INFO | jvm 1 | 2012/05/22 10:46:38 | WrapperManager Debug: Backend not connected, not sending packet STOPPED : 1
INFO | jvm 1 | 2012/05/22 10:46:38 | WrapperManager Debug: calling System.exit(1)
DEBUG | wrapper | 2012/05/22 10:46:38 | JVM process exited with a code of 1, setting the wrapper exit code to 1.
But given my very simple implementation, i cannot guess what is going wrong.

rather than extending WrapperSimpleApp, your main class should implement the org.tanukisoftware.wrapper.WrapperListener interface.
You can find a very detailed description about implementing the interface on our website:
http://wrapper.tanukisoftware.com/doc/english/integrate-listener.html
Please let me know if you have any further questions about the implementation and/or the configuration properties in your conf file.
Another advise which comes in handy for me sometimes, is rather than running your application immediately as service, I find it easier to do the integration by running first as console application, because you can see the output directly on your console. Once everything seems working, I go ahead and install/run as service.
To run as console application, you would run for example:
C:\servicetest\bin>wrapper -c ../conf/wrapper.conf
You can also turn on debug output for the Wrapper by setting
wrapper.debug=true
in your conf file.
Edit due to the comment:
if your application is actually as simple as you describe, then just write your application as normal Java application without any Wrapper API parts.
You can use the WrapperSimpleApp to run your application out of the box with codeless integration into the Wrapper.
All you need to do is set the following properties in your conf file:
wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
wrapper.app.parameter.1=textappender.Main
wrapper.java.classpath.1=../lib/wrapper.jar
wrapper.java.classpath.2=../MyProject.jar
With this configuration, the Wrapper will be able to run your application as windows service.
UPDATE2
I'm not sure what your code exactly looks like, but it seems you are calling WrapperManager.stop() in your main class...
Following the initial example class, I have modified the class, so it is not using any Wrapper-API (which for an simple application is not necessary):
public class Main {
public static void main(String[] args) {
while(true) {
Logger.getLogger(Main.class.getName()).log(Level.INFO, "I'm alive");
try
{ Thread.sleep(2000); }
catch (java.lang.InterruptedException ex)
{ return; }
}
}
}
After compile and creating the jar, the necessary properties in the conf file are:
wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
wrapper.app.parameter.1=textappender.Main
wrapper.java.classpath.1=../lib/wrapper.jar
wrapper.java.classpath.2=../MyProject.jar
cheers,