I have a core java app running on a computer on my network. Can I attach a debugger (netbeans preferred) to this from another computer on the same network?
Please advise how to do this if it is possible, or point me to an article I've had a terrible time googling for it. I don't see why it shouldn't be possible.
Thanks
Yes, you can.
Start your JVM with these arguments:
-Xdebug -Xrunjdwp:transport=dt_socket,address=8001,server=y,suspend=n
The address number is the port number the JVM will listen on for a debugger to attach to. Set suspend to y if you want the JVM to wait until a debugger is attached before starting main.
Your debugger should have the option to connect to a remote JVM. It should be a simple matter of punching in the host and port number.
I assume you mean a java app run from the CL by "core java"? If so
What are Java command line options to set to allow JVM to be remotely debugged?
Once you tell the jvm to listen on a port, just point your netbeans debugging profile to the machine ip and port. This should be very doable.
Related
What is a good system for debugging a multi process Java application where it isn't clear which process should be debugged?
For example, in Python I can use rpdb and add the line import rpdb; rpdb.set_trace() so execution blocks until I connect to the debugger with e.g. nc 127.0.0.1 4444.
Compared to the above quick and reliable method, when I'm using a Java debugger, I see the following challenges:
Ensure that every process is run with proper arguments to allow debugging -- in my case it isn't clear what is starting all the processes so it isn't obvious where to change the arguments. Is there a way to change the defaults on my computer to always include the jvm options -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=1044?
Decide what process to connect the debugger to before the desired code is hit -- again, it isn't clear which process I should connect to, and it is convenient that rpdb blocks until the debugger connects and you don't need to identify the process id. Is there anything similar to this in Java?
Start java with something like:
java -agentlib:transport=dt_socket,server=y,suspend=y,address=1044
The suspend=y bit tells the VM to wait until a debugger connects before running main(). address is the port to connect to.
Scenario 1: I have a test server that gets OS reinstalls on a frequent basis. Is there any way to add a program to the server that will remain and execute even if the OS is reinstalled? (I know it's a stretch, but had to ask)
Scenario 2: I have another server running ESXi 5.1 (which I admit, I know nothing about) how (or can) I run a program at the OS level (not as a VM)? Reason being, I need to get information specific to the server and not the VM's such as ip,MAC address, etc that my program gathers with Runtime.exec().
I have a PXE server setup with kickstart files that work great for linux, but not sure if I can do it with ESX or not, anyone ever try to PXE boot ESX like this? On linux, I run my program via crontab, and in the past did it with rc.local. Any suggestions would be appreciated, even if it is a link to potential resources you have had luck with in similar situations.
1) The program must run within an OS, or the JVM will have been designed to run without an OS. I don't believe there is a JVM which will use an OS if it is there but not care if it is not.
You can do this with virtual machines. You can have the OS run/stop/start/reinstall in a virtual machine, while an application is running on the bare machine or in another virtual machine.
2) When you application runs, it is at the OS level. The distinction is largely an illusion. You can get the IP and MAC addresses in normal Java. If you nee to get something else, you can use JNA/JNI/JNR.
I have not heard of ESX before.
I need to determine the list of JVMs running on a remote machine, and once that is done, to connect to each of the JVMs using JMX. I am a newbie and have gone through the following concepts:
1. using jps and jstat: I read that these commands may not be available in the future jdk versions.
2. using the java class "virtualmachine().list" . The problem with this though is that it helps you fetch the list of JVMs but only for the local machine. I do not know how to connect to a remote machine and then obtain this list.
Can anyone please suggest how to use either "virtualmachine().list" or any other method to obtain a list of JVMs on a remote machine ?
The problem is that all the methods(including the way jconsole works) that I have studied to connect to a remote JVM are focused to a SPECIFIC JVM where I need to provide the port number(of the JVM process). But I need a list of all the JVMs running. How can I do this ? Is it even possible ?
One option would be to launch a small java application on the remote machine and have it run virtualmachine().list or similar and then send back the information or make it accessible using JMX. This application could be running all the time, or you could maybe launch it remotely.
Some other ideas mentioned here: Get System Information of a Remote Machine (Using Java).
You could add a java-agent or some other common component to each of the remote JVMs and have them "phone-home" their JMXServiceURLs to a central JVM clearing house. Other than that, I think your only options are derived broadly from monex0's suggestion.
I'm working in Groovy 1.8.6, running on JDK 1.6.0u33. When my program is starting up, it attempts to connect to another process on the same host by connecting to a telnet port on the host address. It uses the standard Java class InetAddress to determine the local host address. However, for some reason when I start the program up on a Windows XP VM, the host address resolves to garbage and the connection fails.
The startup script includes this line for diagnostic information:
def serverAddress = "http://${InetAddress.localHost.hostAddress}:${config.ServerPort}/DigitizerService?wsdl"
The output when serverAddress is printed to the terminal is:
http://0.1.0.5:8989/DigitizerService?wsdl
The address is not always the same- another time it came out as 0.2.0.5. But it always comes out as something that's not even a valid address, let alone the actual address for this host.
This same codebase is in production on a large number of boxes out in the wild and I've never seen an issue like this coming up, so I guess it must be specific to this new devbox it's on- or it's a bug in the new JDK.
Does anyone have any idea what might be causing something so basic as this to output garbage? Thanks in advance.
While I tried restarting before posting this question (of course, this is Windows after all), and it did not help, a second reboot of the VM seems to have fixed the issue. It was in the process of installing a big pile of Windows updates, as it was an old VM that I'd just dusted off, so I suppose that may have somehow scrambled things internally in the OS.
So I'm still very confused as to how this came about, but I think I can conclude that it was not Java at fault. Probably.
I want to be able to debug production systems with jdwp.
for this I want to add -Xdebug -Xrunjdwp:transport=dt_socket,address=11122,server=y,suspend=n to each java process I am starting.
Is there any overhead for that in case the port is not activated?
is my JVM going to run slower in this case?
AFAIK, the answer is yes.
-Xdebug turns off some runtime optimizations, etc.
In addition, the fact that it's possible to connect to the JVM via jwdp, isn't secure very much. I don't think any production environment should allow this.
If you are not actually connect to this port with remote debugger, overhead will be almost zero (never noticed it in my experience).
-Xdebug makes it's about 5% slower (Java 5, I have no numbers for Java 6) in debug mode because it can't do some kinds of optimizations.
The socket itself doesn't cost much; there is a thread created for it which hangs in accept() (so that doesn't cost anything until someone actually connects to the port).