It sounds a strange question, but there is a reason.
I'm working to use VC++ code auto find out the max memory that JVM can use . I want to use java cmd to launch JVM simply.
My thoughts was:
Running java -Xmx3999G -version like commands and the output, if the JVM is launched successful, there will be something like
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
Otherwise it will output something like
Error occurred during initialization of VM Unable to allocate
131039232KB bitmaps for parallel garbage collection for the r equested
4193255424KB heap. Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Now the key is that how to know whether the JVM is launched or not ? I can find some keywords in output like java version to get know it launched. But the output would be unstable if java update or something else.
The stable way I can think out is running a java code which has unchanged output (just print a simple string in main function can do this). But it needs me to package a jar file in my project's rc and extract it to temp folder and run it in cmd. I think it is little complex.
So I'm asking for help here , can any java command gives me a stable output if JVM is launched ?
How about java -help? Its output would always contain a list of commands, which surely contains a stable subset.
Other than that, you may still decide to retest once a new JDK version appears. It is imho highly unlikely that there are bigger changes in the output. Here's the output from java version 1.6.0_45:
java version "1.6.0_45"
Java(TM) SE Runtime Environment (build
1.6.0_45-b06) Java HotSpot(TM) Client VM (build 20.45-b01, mixed mode, sharing)
and here from java version 1.7.0_75:
java version "1.7.0_75"
Java(TM) SE Runtime Environment (build 1.7.0_75-b13)
Java HotSpot(TM) Client VM (build 24.75-b04, mixed mode, sharing)
These look very similar to 1.8.x except for the version number itself.
Related
I have a brand new Windows 10 Home installation, with a brand-new installation of JDK 10.0.1 (which is what Oracle recommended when I went to the JDK download site.) I just now downloaded Cassandra 3.11.2, un-tar'd it, and put the bin directory on my classpath.
When I attempt to start Cassandra using the cassandra -f command, I get this error:
PS C:\javatools> cassandra -f
*---------------------------------------------------------------------*
*---------------------------------------------------------------------*
WARNING! Automatic page file configuration detected.
It is recommended that you disable swap when running Cassandra
for performance and stability reasons.
*---------------------------------------------------------------------*
*---------------------------------------------------------------------*
Failed 64-bit check. Re-running to get version from 32-bit
*---------------------------------------------------------------------*
*---------------------------------------------------------------------*
Cassandra 3.0 and later require Java 8u40 or later.
Java 10 is clearly "Java 8 rel 40 or later". I verified that I was, in fact, running the version of Java I thought I was:
PS C:\javatools> java -version
java version "10.0.1" 2018-04-17
Java(TM) SE Runtime Environment 18.3 (build 10.0.1+10)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.1+10, mixed mode)
How can I get Cassandra to recognize that I do, in fact, have "Java 8u40 or later"?
Cassandra does not support any Java release newer than Java 8.
References are as follows:
declined bug report against Java 9: CASSANDRA-9608
declined bug report against Java 10: CASSANDRA-14446
Furthermore, even though the documentation does indicate it's a "work in progress", it does indicate the following on the Getting Started page:
Prerequisites
The latest version of Java 8, either the Oracle Java Standard Edition
8 or OpenJDK 8. To verify that you have the correct version of java
installed, type java -version.
While it doesn't explicitly say "Java 9 and newer are not supported", this is apparently supposed to be inferred from this indicator.
Finally, the misleading error message appears to be a wontfix item.
I've managed to run cassandra 3.11.3 on java-11-openjdk-amd64 on localhost (ubuntu 18.04).
(Strangely, java -version shows openjdk version "10.0.1" 2018-04-17)
I tweaked a lot in jvm.options, because many gc options are not supported anymore, and ThreadPriorityPolicy could not be set to 42. (last thing is most annoying: it was really good compaction threads were low priority).
Also, to run nodetool I have to specify jvm 1.8 by JAVA_HOME.
When I try to run intellij, it shows the following message-
Can not start under java 1.7.0_51-b13:Java 1.8 or later is required!
But when I checked the version of the Java in the machine-
java -version
I get-
java version "1.8.0_60" Java(TM) SE Runtime Environment (build
1.8.0_60-b27) Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
What could be the reason for not working this?
Newer versions of IntelliJ IDEA explicitly require Java 8 to run.
Some things that can be done:
Uninstall older versions of Java
Ensure that which java points to the correct version of Java
Ensure that Java 8 is selected via update-alternatives --config java
Check the variables IDEA_JDK, JDK_HOME, and JAVA_HOME, and be sure they don't point to Java 7. If all else fails, IDEA defaults to whichever java is on the path, so unsetting those variables may be a viable option.
Can you check if you have a JAVA_HOME env variable set ? If yes, it might use this version instead of the java binary available in your path.
I configured jmeter to run the test distributed using Azure Windows Virtual Machines. All machines are using windows.
The test ran successfully using the GUI mode and I can get the result saved on master
However when I try to run the test from the console jmeter -n -t plan.jmx -r the console says:
Error in rconfigure() method java.rmi.MarshalException: error marshalling arguments; nested exception is:
java.io.NotSerializableException: org.apache.jmeter.JMeter$ListenToTest
I' ve configured all the virtual machines (server and clients) like:
Java version "1.8.0_65"
Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.65-b01, mixed mode)
Jmeter version 2.13
Jmeter Plugins 1.31
Any ideas what could be the issue?
Thanks
EDIT
I Downgrade Java version to 1.7 and now the error says
Error in rconfigure() method java.rmi.MarshalException: error marshalling arguments; nested exception is:
java.io.NotSerializableException: org.apache.jmeter.threads.RemoteThreadsListenerTestElement
Can Jmeter Plugins the cause of the issue?
EDIT - FIXED
I changed Plugin version from 1.31 to 1.21 and now works!!!.
However I think, and i'm just guessing here, the error happens when I ran the test from GUI and then on the console. Probably GUI leaves a socket open or something like that, not sure.
Anyway this combination works
Java version "1.7.0_79"
Java(TM) SE Runtime Environment (build 1.7.0_79-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode)
Jmeter version 2.13
Jmeter Plugins 1.21 (only Standard Version)
Check the logs in jmeter.log (inside bin folder) file and if you have somewhere an error like this:
2018-09-17 14:41:32,097 ERROR o.a.j.e.ConvertListeners: Error replacing class org.apache.jmeter.threads.RemoteThreadsListenerTestElement by wrapper: class org.apache.jmeter.threads.RemoteThreadsListenerWrapper java.rmi.RemoteException: Cannot start. yout-pc-name is a loopback address.
Then start the jmeter by giving:
./jmeter -Djava.rmi.server.hostname=your_ip_address
I was struggling with:
NotSerializableException: org.apache.jmeter.threads.RemoteThreadsListenerTestElement
The problem in my case was:
Caused by: java.net.BindException: Address already in use (Bind failed)
This error info did not appear in the standard output, just the log file.
I want to try Cassandra. When trying to run Cassandra, writes an error:
Error: Could not find or load main class org.apache.cassandra.service.CassandraDaemon
What's the problem?
Java -version
Java version "1.7.0_67"
Java (TM) SE Runtime Environment (build 1.7.0_67-b01)
Java HotSpot (TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
python --version
Python 2.7.8
You'll get that error when you've downloaded a source distribution of Cassandra but haven't built it or when the CassandraDaemon.class file isn't in your classpath.
For the first problem:
You'll need the JDK 1.7 (which you already have) and ant to build C*.
Navigate to wherever you've extracted cassandra (I'll use ~/cassandra for this explanation) , Run ant and enjoy the awesome.
For the second, if your classpath is setup incorrectly something has gone wrong in the build process or the classpath has been modified. I'd verify that the classpath is what is expected by displaying it in the startup script (the cassandra executable) by adding echo $CLASSPATH near the bottom of the script (in my case it was line 212 for C* 2.1.0).
P.S. On windows you'll need to set CASSANDRA_HOME before being able to run C*.
I downloaded the 32-bit eclipse for my 32-bit fedora 12. I extracted the tar.gz without any error. But when i click on the eclipse executable, i am getting the error:
"Failed to load the JNI shared library "/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/bin/../lib/i386/client/libjvm.so"
"
I am not able to resolve this error. Please inform how to proceed.
Regards,
Go to your eclipse folder
Open eclipse.ini file and check if there is -vm option set properly
Else set -vm in one line followed by your jdk installed bin folder.
Hope this helps yo solve your problem.
I'd suggest avoiding OpenJDK, as Eclipse will keep complaining about it.
So, navigate to http://java.com/en/download/manual.jsp and download appropriate Sun's Java package (32 or 64 bit, depending on your current installation). As Fedora uses RPMs for package management, I advise to use that method.
Then, after installation, run java -version in terminal, you should get something like:
$ java -version
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) Client VM (build 17.1-b03, mixed mode, sharing)