I'm developing a web application with Eclipse and Tomcat on windows. When testing my efforts I sometimes crash Tomcat, and the only option left is to kill the jvm hosting Tomcat, but that can only be done with windows' task manager.
The process to kill is a java process but eclipse is also on a java process and basically the only thing I can do determine which java process to kill is toss a coin and hope for the best. It seems that I choose the wrong (eclipse) java process more often than the tomcat java process. Of course I can and should write down the id of the only java before starting Tomcat but that is sometimes forgotten
Is there a way to determine which java process is for eclipse and which for Tomcat? when eclipse is up an running for a long time I can discriminate on the cpu time, but for short running instances this is no candidate for heurstics.
I use Process Explorer which is free and I can easily see in its GUI (in process tree view) that eclipse is a super node of Tomcat's JVM.
Use the Process Explorer from Sysinternals. It shows the hirarchy of processes, and since the Tomcat got started by Eclipse, you can see it as a “subprocess”.
You could start jvisualvm from the bin of your JDK directory. There each MainClass is listed with the corresponding pid.
Related
I'm starting a java program from IntelliJ Idea which uses a .dll which is written by me in C++. After the startup of the application I can attach to the process using Microsoft Visual Studio (Debug / Attach to Process...) which allows me to debug the C++ part of the running application.
The name of the process is simply java. It is always a pain to select the right one from all the java processes. The simple Task Manager is not sufficient. The Process Explorer is good, but I still need to inspect multiple processes until I find the right one. It would be much easier for me if Idea would just tell the PID of the application it started.
Does Idea have such a feature?
(Win 7 64bit fresh # 2017-04-19, Idea 2017.1.1)
You can list all java processes with the jps utility (Can be executed from Idea terminal window) which makes it extremely easy to identify your process. Example scenario:
D:\projects\git\CENSORED>jps
12084
5476 WorkerMain
8772 WebSocketProxyMain
9444 Launcher
12920 RemoteMavenServer
13400 Bootstrap
7752 Jps
If you have a profiling application like "JProfiler" you can also very easily find the pid in the "quick attach" dialog.
As the title says - when launching Spring app (STS) with embedded Tomcat, both java.exe and javaw.exe processes are created on the same port.
That means I have troubles with busy port, even when using the Relaunch option (which typically shuts Tomcat down and then restarts it). Indeed, relaunching does stop one of the two processes but then I get an error stating that the port must be busy. Killing the remaining one does solve the issue but I life is too short to both develop in Java AND kill the process manually.
Is there a convenient way to overcome this? I see that is STS (and Eclipse too, of course) there's a way to specify project specific JRE but I'm unsure on how to proceed.
Note: I have both 32- and 64-bit java8 instances installed.
Try running it as a java application (ie, just run main).
It sounds like you are deploying it on Tomcat, while at the same time there is an embedded Tomcat being started... :)
i have deployed a java server using my eclipse.
I extract the war file.
i installed the apache-tomcat-7.0.47 on my windows server 2003
i installed the Apache Tomcat 7 service on my windows server 2003 and made it run automatically.
i want to run the war file on my windows server 2003
what i have tried
i put the war file on my webapps on the apache-tomcat folder and then run the startup.bat which locates on the bin folder.
i test the server and it works perfectly
my problem
when i log of from my windows server. the war file stop working.
my question
how can i keep the server working ever when i log of. note that i installed the service and restart the server many times.
One way to do this is to use a Java Server Wrapper or http://support.microsoft.com/kb/137890
SO Link
There seems to be a way in java itself to do this, add -Xrs to your java.exe call in server startup (bat file I suppose), from Oracle Documentation . Beware of the consequences in using this!
-Xrs Reduces use of operating-system signals by the Java VM.
In an earlier release, the Shutdown Hooks facility was added to enable
orderly shutdown of a Java application. The intent was to enable user
cleanup code (such as closing database connections) to run at
shutdown, even if the Java VM terminates abruptly.
The Java VM watches for console control events to implement shutdown
hooks for unexpected Java VM termination. Specifically, the Java VM
registers a console control handler which begins shutdown-hook
processing and returns TRUE for CTRL_C_EVENT, CTRL_CLOSE_EVENT,
CTRL_LOGOFF_EVENT, and CTRL_SHUTDOWN_EVENT.
The JVM uses a similar mechanism to implement the feature of dumping
thread stacks for debugging purposes. The JVM uses CTRL_BREAK_EVENT to
perform thread dumps.
If the Java VM is run as a service (for example, the servlet engine
for a web server), then it can receive CTRL_LOGOFF_EVENT but should
not initiate shutdown because the operating system will not actually
terminate the process. To avoid possible interference such as this,
the -Xrs command-line option was added beginning with J2SE 1.3.1. When
the -Xrs option is used on the Java VM, the Java VM does not install a
console control handler, implying that it does not watch for or
process CTRL_C_EVENT, CTRL_CLOSE_EVENT, CTRL_LOGOFF_EVENT, or
CTRL_SHUTDOWN_EVENT.
There are two consequences of specifying -Xrs:
Ctrl-Break thread dumps are not available.
User code is responsible for causing shutdown hooks to run, for
example by calling System.exit() when the Java VM is to be terminated.
After reading aksappy's answer. I discovered that the jvm is making that problem. i went to the bin folder of the apache-tomcat and run the tomcat7w.exe and then I went to the shutdown tab and changed the jvm to java.
this is the facinate solution that helped me
You can set the “deployIgnore” attribute for your web application in server.xml ; this attribute will ignore the war file name from deployment. Later you can deployment the application manually
I'm running a number of java processes on a windows XP professional machine. When i attempt to connect to these processes via a local JConsole the processes are grayed out.
However i can run the same processes on another machine and connect via a local JConsole on that machine.
Both machines are running java 1.6 version for the processes and jconsole.
Any ideas why these processes are grayed out?
I'm fighting with this issue right now and I found out a work around:
You can change the local user's temp dir to something that they can definitely access (e.g. D:\temp). Make sure to do this for the process you're trying to monitor and the jconsole process.
Another thing that can apparently cause issues are usernames with uppercase letters in them. The directory will always be created with all lowercase letters, but simply renaming it to exactly how it's being shown in the Task Manager made all the issues go away: http://planeofthought.com/wp/?p=75
if the processes are running as a different user (e.g. if you start them as services), then you won't be able to connect to them. also, if they are running under an older jvm, you most likely won't be able to talk to them either.
in some cases, the local jmx communication mechanism uses the local filesystem and may have issues if permissions are not defined correctly. are you possibly running any of these processes on networked filesystems (nfs, samba)?
Say your windows user name you use to start your java application seen in task manager is YOUR_USER_NAME.
Please check a folder whose name looks like hsperfdata_XXXXX (XXXXX should be your user name) in your temp folder and make sure YOUR_USER_NAME and XXXXX are exactly the same (be careful about the upper and lower case).
From http://download.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html:
Applications that are not attachable, with the management agent disabled. These include applications started on a J2SE 1.4.2 platform or started on a J2SE 5.0 platform without the -Dcom.sun.management.jmxremote or com.sun.management.jmxremote.port options. These applications appear grayed-out in the table and JConsole cannot connect to them. In the example connection dialog shown in Figure 3-1, the Anagrams application was started with a J2SE 5.0 platform VM without any of the management properties to enable the JMX agent, and consequently shows up in gray and cannot be selected.
(source: oracle.com)
Despite what's being written in the documentation, most likely your process is running under a different user. You can run jconsole as an administrator and try then.
Here is what worked for me. I changed my %TEMP% and %TMP% environment variables to point to a folder I created in my %HOME% location (like C:\Users\[YOUR_NAME]\Temp). Once I did this, all problems vanished.
I had the problem as described earlier, but was advised a simpler solution: just close all programs using Java ("IntelliJ IDEA", "SoapUI", etc. - to unlock the temporary folder) and then delete %TMP%\hsperfdata_<user.name> folder. Then, after opening any Java program, this folder will be recreated but this time with correct name (most likely %TMP%\hsperfdata_<User.Name>). And after that, local Java processes can be monitored through "JConsole" or "VisualVM" (now runs without starting error with a link to VisualVM: Troubleshooting Guide) again.
instead of this steps you can just goto the CMD and then type in jconsole.exe (PID)
Remember to go to the path where jconsole is present and then run the executable file.
Change the name of the hsperfdata folder which for me was found at C:\Users\pmimgg0\AppData\Local\Temp\hsperfdata_pmimgg0 to match the User name found on task manager. Once I changed hsperfdata_pmimgg0 to hsperfdata_PMIMGG0 my local process was no longer greyed out on jconsole.
Change your TEMP paths in Environment Variables to something like D:\temp as it could be a permission issue. Fixed this issue for me
The best way is to run local process like a remote process.
Add these conditions in runtime arguments -
-Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.port=6001
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Djava.rmi.server.hostname=localhost
-Dcom.sun.management.jmxremote.rmi.port=6001
Then select Remote Process and point to localhost:6001 as shown
Click Connect and Jconsole is connected successfully.
For me this fixed as I had some admin constraints.
I've noticed that when I start Netbeans it shows up in the task manager as netbeans.exe as all my own Java applications show up as java.exe or javaw.exe.
How can I change that so my process names shows up as myapp.exe?
The process name is the name of the JVM. So if you rename the jvm you have an other process name. There are some tools which can do that for you. For example Launch4J
IMO the best option is to choose one of the many open source launchers. They all provide a nicer deployment container than java.exe and a batch file.
I've compiled a list of them after a brief search on google (in no particular order and may not be exhaustive):
NSIS
Janel (dead link)
JSmooth
Launch4J
WinRun4J
(full disclosure: i work on winrun4j)
Not easily. The easiest way (but not nice!) would be to simply copy the java.exe (only 68k on my system, so perhaps practical!)
If you're worried about identifying which java process is which (e.g. is one consuming memory/CPU etc.), use the standard tool jps to identify the Java processes
Netbeans and Eclipse both ship with an .exe file that in turns launches a JVM. The exe itaself probably does nothing after launching the VM. You see the NetBeans javaw.exe in the Task Manager also, I suspect.
So you'll need to write a native exe (using some windows tool) that does a similar thing.
Just answered this a second ago here: Get JVM to grow memory demand as needed up to size of VM limit?
It's actually a lot easier than folks are saying (but you do have to have a c/c++ compiler handy).
There are mainly 2 approaches: one is as already described: using tools like Launch4j, WinRun4J to create native Windows launchers.
Another approach that seems better is to use Apache Procrun to wrap the java application as a Windows service. During the install service process, we can give the process an meaningful name such as OurApp.exe.
All we need do is rename prunsrv.exe to OurApp.exe and replace every occurrence of prunsrv.exe in our install|start|stop|uninstall service scripts to MyApp.exe.
See more from Using Apache Procrun to Rename Process Name of a Java Program in Windows