We Keep Coding

Error in starting cassandra in windows 10 PC

I had downloaded the Cassandra software and installed the dependencies i.e. Python and Java. Then in cmd I wrote the following command.
C:\apache-cassandra-3.11.10\bin>cassandra
It gave the following output
WARNING! Powershell script execution unavailable.
Please use 'powershell Set-ExecutionPolicy Unrestricted'
on this user-account to run cassandra with fully featured
functionality on this platform.
Starting with legacy startup options
Starting Cassandra Server
Unrecognized VM option 'UseParNewGC'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
My java version is:
C:\apache-cassandra-3.11.10\bin>java --version
java 16 2021-03-16
Java(TM) SE Runtime Environment (build 16+36-2231)
Java HotSpot(TM) 64-Bit Server VM (build 16+36-2231, mixed mode, sharing)
Does Cassandra 3.11.10 support Java-16?

Set the appropriate execution policy in Powershell.
Cassandra 3 only works with Java 8 and lower.
The other possibility for you is to run Cassandra on WSL (Windows Subsystem Linux).

CPU and profiling not supported for remote jvisualvm session

When monitoring a remote app (using jstatd) I can neither profile nor monitor CPU consumption. Heap monitoring (provided I do not use G1) works. jvisualvm provides the message "Not supported for this JVM." in the CPU graph window.
Is there anything missing in my setup? Google showed very few results.
The local environment (Mac OS X 10.6):
java version "1.6.0_15"
Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219)
Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-90, mixed mode)
The remote environment (Linux version 2.6.16.27-0.9-smp (gcc version 4.1.0 (SUSE Linux))):
java version "1.6.0_16" Java(TM) SE
Runtime Environment (build
1.6.0_16-b01) Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
Local monitoring works as advertised.

Remote profiling of code and allocation isn't supported by Visual VM. This sucks, however if you want to enable the CPU graph you can do this by enabling JMX with
-Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.port=12345
You may need to add some authentication settings too based on your network. The JMX settings will give you the CPU usage, and thread state, as well as doing a remote jstack.
A list of features for the remote version can be found here:
Visual VM features
EDIT
Get the latest version of visual vm 1.2.1 and download the VisaulVM-Sampler. This will read from a JMX connection to show the profiling information.

Connecting the eclipse java program.
Step 1: ensure your Eclipse -> Preferences -> Java -> Installed JREs is pointing to the same jdk where you have started the visualvm.
Step 2: Ensure Right click -> Run configuration has the following
-Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.port=16001
Step 3: Importantly follow the below suggestion.
https://visualvm.java.net/troubleshooting.html#jpswin2
Description: An error dialog saying that local applications cannot be monitored is shown immediately after VisualVM startup. Locally running Java applications are displayed as (pid ###).
Resolution: This can happen on Windows systems if the username contains capitalized letters. In this case, username is UserName but the jvmstat directory created by JDK is %TMP%\hsperfdata_username. To workaround the problem, exit all Java applications, delete the %TMP%\hsperfdata_username directory and create new %TMP%\hsperfdata_UserName directory.
Also try JVMMonitor is decent plugin for eclipse stand alone program monitoring.

Is it because the remote version is (albeit slightly) greater than the local version?

I'm able to resolve this issue by providing same port number for JMX and RMI.
-Dcom.sun.management.jmxremote.port=29898
-Dcom.sun.management.jmxremote.rmi.port=29898
See Why Java opens 3 ports when JMX is configured?

How to make sure I'm using the "server" JVM?

Sun's JVM comes in two flavors: -client and -server, where the Server VM is supposed to be optimized for long running processes, and is recommended for server applications.
When I run java with no parameters, it displays the usage options, which includes the following text:
The default VM is server,
because you are running on a server-class machine.
Having seen this, I didn't bother to add the -server to the process startup command.
However, on a recent JVM crash log, I noticed the following line near the end of the file:
vm_info: Java HotSpot(TM) Client VM (14.0-b16) for linux-x86 JRE (1.6.0_14-b08), built on May 21 2009 02:01:47 by "java_re" with gcc 3.2.1-7a (J2SE release)
It seems to me that Java is using the Client VM, despite what it says in the help message. I'm going to add the -server option to my startup command, but now I'm suspicious. So my question is: is there a way to make sure that the VM I'm running in is really the Server VM, without resorting to forcing a JVM crash?
The OS is ubuntu 8.04, but I'm using JDK 1.6.0_14 which I downloaded from Sun's website.

You can do
System.out.println(System.getProperty("java.vm.name"));
Which on my machine returns either:
Java HotSpot(TM) Client VM
or
Java HotSpot(TM) 64-Bit Server VM
Of course you shouldn't do anything critical based on this value, as it will probably change in the future, and will be completely different on another JVM.

I had a very similar question which I asked on ServerFault. I would say, if you care which version is run, always use -client or -server.

Well, if you explicitly start with the -server command line prompt, you are running in server mode. You can check that with this:
ManagementFactory.getRuntimeMXBean().getInputArguments();
You can look at RuntimeMXBean which may open up more information, but that would have to be tested on the specific JVM you are running.

Without writing any single line of code, if you use JConsole to connect to your JVM, under 'VM Summary' tab, it should say exactly which (server or client) Virtual Machine is being monitored.
For example,
Virtual Machine: OpenJDK Server VM version 1.6.0-b09
To remotely monitor your JVM using JConsole, simply enable the JMX (Java Management Extensions) agent by starting JVM with the following System Properties
> java.rmi.server.hostname=[your server IP/Name] // without this, on linux, jconsole will fail to connect to the remote server where JVM is running
> com.sun.management.jmxremote.authenticate=false
> com.sun.management.jmxremote.ssl=false
> com.sun.management.jmxremote.port=[portNum]

How to get remote debugging work for Java on Solaris

I am trying to get remote debugging working with Java on Solaris OS. Following is what I have tried-
I have a Java class called TestP which has the main method.
When I try
java -classpath . TestP
the program works fine. But when I try adding the debug parameters to the JVM-
java -Xdebug -Xrunjdwp:transport=dt_socket,address=8001,server=y,suspend=n -classpath . TestP
It fails giving this error-
UTF ERROR ["../../../src/solaris/npt/utf_md.c":49]: Failed to complete iconv_open() setup
Can anyone please help me on figuring out why this error is coming up?? The above works fine on my Linux box.
Java version on Solaris:
Java(TM) SE Runtime Environment (build 1.6.0_15-b03)
Java HotSpot(TM) Client VM (build 14.1-b02, mixed mode)
Java version on Linux:
java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.5) (fedora-20.b16.fc10-i386)
OpenJDK Server VM (build 14.0-b15, mixed mode)

Hmm... This seems to be a known Solaris (not specific to Solaris 10) issue with Java 6, not a Java issue (see this thread).
Someone has successfully applied a workaround (see this blog post) from a Sun guy, Jeff Moguillansky, but I wouldn't recommend it and rather consider searching sunsolve for a patch as indicated on Sun's forums.
Look at this one: http://sunsolve.sun.com/search/document.do?assetkey=1-1-6586755-1 (you'll need a Sun Online Account with a valid Support Contract or Software Subscription).

Using truss I found out that the process was looking for /usr/lib/iconv/geniconvtbl/binarytables/UTF-8%646.bt and 646%UTF-8.bt, so I just copied ISO8859-1%ISO646.bt to UTF-8%646.bt and ISO646%ISO8859-1.bt to 646%UTF-8.bt (yes, it is "646", not "ISO646"!)
This is of course a very ugly workaround and I have no idea if it has any negative effects on the JVM, but at least it starts the JVM without aborting. (I did this on OpenSolaris 2009.06, btw)

If Pascal Thivent is right, then you may want to try running OpenSolaris (either on a blank machine or in a vm) and see if the problem is also there. If not, then consider using that version for now if possible.

how to tell if VM is running in server or client mode?

The Java hotspot vpm can be run with -client or -server argument. If neither is specified then it chooses one according to some rules.
Is it possible to tell whether a running VM is running in client or server mode when the mode is not specified on command line? I need this on a Windows box outside the running process.
I realize this is not a programming question, but I hope it is ok because it is programming related. Thanks in advance.

In Java, you could check this with this code:
String s = System.getProperty("java.vm.name");
// s = Java HotSpot(TM) Server VM
But this will be highly vendor specific.
From the command line, you could use jinfo (used to check a value of a given HotSpot VM option)
C:\>"c:\Program Files\Java\jdk1.6.0_16\bin\jps.exe" -l -m
21812 sun.tools.jps.Jps -l -m
19244 (eclipse)
C:\>"c:\Program Files\Java\jdk1.6.0_16\bin\jinfo.exe" -flag NewRatio 19244
-XX:NewRatio=12
Since:
it is rare to actually set the NewRatio Hotpot option and
the documentation specifies: Ratio of new/old generation sizes. [x86 -server: 8; x86 -client: 12]
12 means "Client".

Connect to the running Java process with jvisualvm. This will let you see the JVM arguments that have been used.

You can retrieve this information connecting to the MBean server. If you are running a Sun VM, you have an MBean with name "java.lang:type=Runtime" which exposes the attribute "VmName", whose value is the same as system property "java.vm.name". In example, for a server vm the value will be something like "Java HotSpot(TM) Server VM". VM's from other vendors may use a similar mechanism.
You can connect to the MBean server either using the tools included in the JDK, like jconsole or jvisualvm, or by writing your own tool using JMX if you need programmatic access.

If the jvm is started with -debug, you can connect to it using jdb, and use eval ...
eval System.getProperty("java.vm.name");
that or jinfo