My WebLogic Servers use JRockit JVM R28. We need to have the WebLogic JVMs configured to automatically shutdown/kill/exit when an OutOfMemoryError occurs.
A JRockit JVM Parameter called "ExitOnOutOfMemory" will let us accomplish this. However Oracle documentation provides incorrect and conflicting information.
1.) http://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/jrdocs/refman/optionXX.html says to simply put "-XXexitOnOutOfMemory" into startup scripts. However, JRockit doesnt "recognize" this parameter.
2.) http://docs.oracle.com/cd/E15289_01/doc.40/e15062/optionxx.htm#BABCDAIB says to put "-XX:+ExitOnOutOfMemoryError" into startup scripts. However JRockit does not recognize this configuration either. I believe they mistakenly copied this from Hotspot documentation.
How do i implement this parameter?
-XX:+ExitOnOutOfMemoryError works as expected with JRockit R28.2.2:
$ jrockit-jdk1.6.0_29/bin/java -Xmx20m -XX:+ExitOnOutOfMemoryError OOM
java.lang.OutOfMemoryError: allocLargeObjectOrArray: [B, size 40976
at jrockit/vm/Allocator.allocLargeObjectOrArray(JIZ)Ljava/lang/Object;(Native Method)
at jrockit/vm/Allocator.allocObjectOrArray(Allocator.java:349)
at jrockit/vm/Allocator.allocArray(Allocator.java:257)
at OOM.<init>(OOM.java:3)
at OOM.main(OOM.java:9)
at jrockit/vm/RNI.c2java(JJJJJ)V(Native Method)
-- end of trace
[ERROR] Exit on OutOfMemory requested. Exiting.
JRockit aborted: Exit requested on OOM (51)
Which version of JRockit are you using? Did you spell the parameter correctly?
Related
I've been running a Ktor server application locally and deploying to Heroku for the last several months without any issues. However after deploying the latest version, I started to see the following error on any POST requests trying to process the request body on Heroku:
java.lang.NoSuchMethodError: java.nio.ByteBuffer.limit(I)Ljava/nio/ByteBuffer;
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at io.ktor.utils.io.ExceptionUtilsJvmKt$createConstructor$$inlined$safeCtor$3.invoke(ExceptionUtilsJvm.kt:103)
at io.ktor.utils.io.ExceptionUtilsJvmKt$createConstructor$$inlined$safeCtor$3.invoke(ExceptionUtilsJvm.kt:90)
at io.ktor.utils.io.ExceptionUtilsJvmKt.tryCopyException(ExceptionUtilsJvm.kt:66)
at io.ktor.utils.io.ByteBufferChannelKt.rethrowClosed(ByteBufferChannel.kt:2456)
at io.ktor.utils.io.ByteBufferChannelKt.access$rethrowClosed(ByteBufferChannel.kt:1)
at io.ktor.utils.io.ByteBufferChannel.readRemaining$suspendImpl(ByteBufferChannel.kt:2126)
at io.ktor.utils.io.ByteBufferChannel.readRemaining(ByteBufferChannel.kt)
at io.ktor.utils.io.ByteReadChannelKt.readRemaining(ByteReadChannel.kt:217)
at io.ktor.serialization.SerializationConverter.convertForReceive(SerializationConverter.kt:158)
at io.ktor.features.ContentNegotiation$Feature$install$3.invokeSuspend(ContentNegotiation.kt:224)
at io.ktor.features.ContentNegotiation$Feature$install$3.invoke(ContentNegotiation.kt)
at io.ktor.features.ContentNegotiation$Feature$install$3.invoke(ContentNegotiation.kt)
at io.ktor.util.pipeline.SuspendFunctionGun.loop(SuspendFunctionGun.kt:248)
at io.ktor.util.pipeline.SuspendFunctionGun.proceed(SuspendFunctionGun.kt:116)
at io.ktor.util.pipeline.SuspendFunctionGun.execute(SuspendFunctionGun.kt:136)
at io.ktor.util.pipeline.Pipeline.execute(Pipeline.kt:78)
at io.ktor.request.ApplicationReceiveFunctionsKt.receive(ApplicationReceiveFunctions.kt:116)
at io.ktor.request.ApplicationReceiveFunctionsKt.receiveOrNull(ApplicationReceiveFunctions.kt:135)
Thinking that there might be something unexpected with the request body, I first tried changing call.receive<MyObject>() to call.receiveOrNull<MyObject>(), yet the issue persisted.
I got tipped off that this might be a JVM mismatch issues, so I checked Heroku's Java documentation and learned that the default JVM is 1.8. I then ran my application locally with Java 1.8 and was able to re-create the same behavior.
After changing the target JVM on Heroku for my application to version 11, this has apparently fixed the problem. While I did recently add the Ktor Authentication "feature", I can't see any other changes that might have caused this. I tried to find in the Ktor documentation what the minimum required JVM target is and was not able to find it. It's great that it's working again, but I'd like to have more confidence moving forward.
In order to ensure proper execution of the server and to avoid this kind of issue in the future, I'd like to ask what the supported JVM target(s) are for Ktor Server (and if possible, have this added to the Ktor documentation).
I solved by upgrding to ktor_version:1.6.7.
Iam facing JVM Crash cosistently while enabling hotdeploy (USING below java options on starting up JAVA_OPTS -Xmx4096m -XX:MetaspaceSize=512m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=crash -XX:ThreadStackSize=512 -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=5 -XX:NewRatio=2 -XX:+UnlockDiagnosticVMOptions -XX:-UseLoopPredicate -Xdebug -Xrunjdwp:transport=dt_socket,address=$DEBUG_PORT,server=y,suspend=n -XX:NewRatio=2 -Dspringloaded.synchronize=true JAVA_OPTS=`echo $JAVA_OPTS -Dspringloaded.synchronize=true -javaagent:springloaded-1.2.1.jar -noverify
)
Environment : JDK 1.8 U 66, RHEL 6.7
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007faee9a1e27c, pid=27208, tid=140379827795712
#
# JRE version: Java(TM) SE Runtime Environment (8.0_66-b17) (build 1.8.0_66-b17)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.66-b17 mixed mode linux-amd64 )
# Problematic frame:
# V [libjvm.so+0x35027c] Canonicalizer::do_If(If*)+0x1c
#
# Core dump written. Default location: core.27208
#
# An error report file with more information is saved as:
# hs_err_pid27208.log
# [ timer expired, abort... ]
I've noticed both -javaagent and -noverify in Java options list.
It looks like springloaded agent generates invalid bytecode, while the bytecode verification is explicitly turned off. No surprise, this may lead to unpredictable results including JVM crash.
This is not a JVM problem, but most likely a bug in springloaded agent. Try to remove -noverify option.
-XX:-TieredCompilation may also work around this particular problem, but don't expect application to work correctly if the bytecode fails to pass verification. It's better to stay away from the buggy agent libraries.
4.2.1 Crash in HotSpot Compiler Thread or Compiled Code
If the fatal error log indicates that the crash occurred in a compiler
thread, then it is possible (but not always the case) that you have
encountered a compiler bug. Similarly, if the crash is in compiled
code then it is possible that the compiler has generated incorrect
code.
In the case of the HotSpot Client VM (-client option), the compiler
thread appears in the error log as CompilerThread0. With the HotSpot
Server VM there are multiple compiler threads and these appear in the
error log file as CompilerThread0, CompilerThread1, and AdapterThread.
Below is a fragment of an error log for a compiler bug that was
encountered and fixed during the development of J2SE 5.0. The log file
shows that the HotSpot Server VM is used and the crash occurred in
CompilerThread1. In addition, the log file shows that the Current
CompileTask was the compilation of the java.lang.Thread.setPriority
method.
An unexpected error has been detected by HotSpot Virtual Machine:
:
Java VM: Java HotSpot(TM) Server VM (1.5-internal-debug mixed mode) :
--------------- T H R E A D ---------------
Current thread (0x001e9350): JavaThread "CompilerThread1" daemon
[_thread_in_vm, id=20]
Stack: [0xb2500000,0xb2580000), sp=0xb257e500, free space=505k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
C=native code) V [libjvm.so+0xc3b13c] :
Current CompileTask: opto: 11 java.lang.Thread.setPriority(I)V
(53 bytes)
--------------- P R O C E S S ---------------
Java Threads: ( => current thread ) 0x00229930 JavaThread "Low
Memory Detector" daemon [_thread_blocked, id=21]
=>0x001e9350 JavaThread "CompilerThread1" daemon [_thread_in_vm, id=20] :
In this case there are two potential workarounds:
The brute force approach: change the configuration so that the application is run with the -client option to specify the HotSpot
Client VM.
Assume that the bug only occurs during the compilation of the setPriority method and exclude this method from compilation.
The first approach (to use the -client option) might be trivial to
configure in some environments. In others, it might be more difficult
if the configuration is complex or if the command line to configure
the VM is not readily accessible. In general, switching from the
HotSpot Server VM to the HotSpot Client VM also reduces the peak
performance of an application. Depending on the environment, this
might be acceptable until the actual issue is diagnosed and fixed.
The second approach (exclude the method from compilation) requires
creating the file .hotspot_compiler in the working directory of the
application. Below is an example of this file:
exclude java/lang/Thread setPriority
In general the format of this file is exclude CLASS METHOD, where
CLASS is the class (fully qualified with the package name) and METHOD
is the name of the method. Constructor methods are specified as
and static initializers are specified as .
Note - The .hotspot_compiler file is an unsupported interface. It is
documented here solely for the purposes of troubleshooting and finding
a temporary workaround.
Once the application is restarted, the compiler will not attempt to
compile any of the methods listed as excluded in the .hotspot_compiler
file. In some cases this can provide temporary relief until the root
cause of the crash is diagnosed and the bug is fixed.
In order to verify that the HotSpot VM correctly located and processed
the .hotspot_compiler file that is shown in the example above, look
for the following log information at runtime. Note that the file name
separator is a dot, not a slash.
Excluding compile: java.lang.Thread::setPriority
Source
Agree with #apangin, In the program you are doing bytecode intrumentation (-agent) but specifies -noverify. When verification is turned off, you may end up such crashes.
You should not use -noverify or -Xverify:none during byte code intrumentation.
For those of you unfamiliar with bytecode verification, it is simply part of the JVM's classloading process that checks the code for certain dangerous and disallowed behavior. You can (but shouldn't) disable this protection on many JVMs by adding -Xverify:none or -noverify to the Java command line. https://blogs.oracle.com/buck/entry/never_disable_bytecode_verification_in
I'm trying to install Stardog, but it sends me this error:
Exception in thread "main" java.lang.UnsupportedClassVersionError: JVMCFRE003 bad major version; class=com/complexible/stardog/cli/admin/CLI, offset=6
at java.lang.ClassLoader.defineClassImpl(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:275)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:69)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:540)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:451)
at java.net.URLClassLoader.access$300(URLClassLoader.java:79)
at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:1038)
at java.security.AccessController.doPrivileged(AccessController.java:284)
at java.net.URLClassLoader.findClass(URLClassLoader.java:429)
at java.lang.ClassLoader.loadClass(ClassLoader.java:660)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:358)
at java.lang.ClassLoader.loadClass(ClassLoader.java:626)
Could not find the main class: com.complexible.stardog.cli.admin.CLI. Program will exit.
Does anybody know how to solve it?
Errors of this kind typically mean the code you are attempting for run is for a different version of Java than you are trying to run.
Stardog requires Java 8:
Stardog runs on Java 8
So please ensure you are running it under Java 8, providing the output of java -version in your environment as part of your question would be helpful in determining if this is your problem.
We are facing a VerifyError in our application while deploying to WAS environment. The following is the exception:
Error 500: org.springframework.web.util.NestedServletException: Handler processing failed; nested exception is java.lang.VerifyError: JVMVRFY012 stack shape inconsistent; class=com/org/jaxb/Input_JAXB_Deserialization_Stub, method=write(ILjava/lang/Object;)V, pc=356
We are still trying to identify the issue, but all efforts not going well. Is there any way that the libraries used in run time is good in bytecode compatibility?. For example, we can add all the libraries and run the byte code verification.
I have install latest version of IBM Worklight on Marketplace of eclipse juno. I have create a new project and then run my project Run As > Run on Worklight Development Server. then i have face an error on the server. Please Help me.
Thanks
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
objc[42627]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_20.jdk/Contents/Home/jre/bin/java and /Library/Java/JavaVirtualMachines/jdk1.8.0_20.jdk/Contents/Home/jre/lib/libinstrument.dylib. One of the two will be used. Which one is undefined.
ERROR: transport error 202: bind failed: Address already in use
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [debugInit.c:750]
FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
/Users/apple/Downloads/eclipse 2/plugins/com.worklight.studio.plugin_6.2.0.00-20140904-1709/liberty/wlp/bin/server: line 710: 42627 Abort trap: 6 "${JAVA_CMD}" "$#"
Your Log says Address Already in use. Restart your eclipse. Make sure process is killed.
Either your eclipse did not exit gracefully or some other application is using the port.
If some application is using the port go to server view of eclipse, expand "worklight development server" and change port in "server.xml" file. Hope that helps
According to your error message it is clearly saying that address already in use , this means the port number id using java.exe in background process.so this time if you stop server also this will not release.For this please do the following.
1.Download TCPView from http://technet.microsoft.com/en-us/sysinternals/bb897437.aspx for windows.
2.Install TcpView , after that you will find the port number say 10080.Right click on port number and end process.Now Clean the project and run the server.
Hope this helps.