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.
Related
We have a kiosk that runs processes from a service that acts as a monitor. That service runs as the system user. When java.exe tries to load a JAR file from a server that allows TLSv1.2 only, the download fails. We believe this is because when java.exe runs in this way, it doesn't see all the configurations (at least partially because the system user doesn't have an HKCU profile entry).
Is that correct? Is there a way to overcome it? We've tried -Dhttps.protocol=TLSv1.2 in all conceivable environments, we've tried invoking the Java control panel from all the environments (including the system user), and we've run out of ideas. It seems to be ignoring the Java console settings as well--so we can't look at a log to see what's happening.
We're at wit's end with it and not sure what to try next. Any ideas on how to overcome this or at least diagnose it further?
You can set an environment variable to a pass a global java properties to all running JRE.
In your case, try to set _JPI_VM_OPTIONS as a system variable to make it global.
For an applet, try this
_JPI_VM_OPTIONS = -Dhttps.protocol=TLSv1.2
ref: https://docs.oracle.com/javase/7/docs/webnotes/tsg/TSG-Desktop/html/plugin.html
It turns out the answer involves installation policies, which our team thought was a pretty obscure thing to go wrong. They're looking at changing the platform installer now
I've got a Talend process, deployed inside a .war file in a Tomcat app server. The .war has several jobs inside it, that are called using a get request pretty much like "http://server:port/TalendProject/method=runJob".
Not having the commercial license of Talend (using Open Studio at the moment) I don't have any way to control whether a job has failed or not in the middle of the execution.
I know I can check logs but not knowing the system I'm operating with, I can't be sure if a job has failed or is still running (after an exception for example).
My question is if there is any way to monitor the job that is running inside the Tomcat, this is, if there is any way to show the process that is being running.
My guess, but I'm not sure is that there is no way since the Talend Job is running encapsulated by the Talend .war, so the only thing I will see is the java calling this .war and everything below will be hidden.
I don't know anything about Talend, but I think you can use JConsole or better VisualVm to monitor your Tomcat server via JMX Agent. In order to monitor any Java application (as Tomcat) you have to invoke it with -Dcom.sun.management.jmxremote if tomcat is running in localhost.
If Tomcat is running in another host, you need to configure at least port JMX property -Dcom.sun.management.jmxremote.port=XXXX.
In order to add these properties to run tomcat, you have to change CATALINA_OPTS variable located into $TOMACT_HOME\bin\catalina.sh or $TOMACT_HOME\bin\catalina.bat file.
You have full documentation about Java JMX Agent monitoring here
This way you can monitor threads, memory consumption, gc activity, do profiling, thread dump, ... maybe it helps you to understand .
I'm writing a program in java and I was curious as to whether there was any command or code that could be added to make it always run on startup. For example once someone downloads the program it runs whenever they log into their computer. I'm not sure if this matters but I'm writing it in the Netbeans IDE.
You could give your application an option (user can choose it) that will create an entry in the startup/run-once part of the operating system. On windows you could write to the registry to set the option (maybe program need higher priv. to do that) or you could put a link to the startup folder. This might depend on the operating system.
Try Java Service Wrapper
http://wrapper.tanukisoftware.com/doc/english/introduction.html
This lets you run a Java application as a Windows Service or UNIX Daemon.
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.
I'm trying to run jstack command on my java application. Application is rather big, running inside jboss AS occupying about 4gb of memory. OS is Windows Server 2003 Standard edition. Every time i get an error "Not enough storage is available to process this command". There is enough ram, 16gb, and disk space. So, any ideas?
I ran into this recently on Win2008r2 and thought I'd share my solution since it took a while to figure out. Rob's comment about psexec -s is what did it for me.
It appears that on Vista and later jstack doesn't work against services because of the user context. It has nothing to do with memory. I suspect this is the same reason people have seen this problem on 2003 via remote desktop, unless you use the /admin or /console switch on mstsc. As of Vista the tightened security is probably what broke it.
Starting my app from a cmd window worked fine, but that doesn't help me debug our standard install. Enabling the java debug port (for VisualVM, Eclipse or most any Java debugger) requires an app restart, so you lose the state you're probably trying to capture if you don't already have debugging enabled. Starting the service under my user credentials did not work - I was a little surprised at that. But psexec -s runs jstack from the system context, which worked like a charm. Oh, and you'll need to run psexec from an elevated cmd prompt, if UAC is on.
In the past I have seen this when the JVM is running as a Windows Service on Windows 2003.
First, check to see if this is an issue with the TMP directory.
Second, jstack (or the other utilities like jconsole) will not connect to the local process unless it is running in the same session. If the service is running as a specific user, you may be able to connect by logging into the same session. If you are using Remote Desktop, you can connect using "mstsc /admin" (used to be /console) and try to run jstack again. Definitely check to make sure the TMP directory is set properly if this doesn't fix the problem.
If the service is running as LocalSystem, the above procedure probably will not help much. I don't know if there is a way to log into the same session as LocalSystem.
Some other alternatives may be to set the process up for remote monitoring and use jvisualvm (from the server itself or another machine) to connect over a port and do a thread dump.
We had problems running JStack on a Windows machine with even a modest application (1GB). We ended up doing our stack and heap analysis using Netbeans. This seemed to cope with the parsing of dump files a lot better. YMMV.
Give Netbeans a try for profiling - its very good. Note that VisualVM is a cutdown NB profiler and comes with 6u7.
psexec -s jstack PID >> c:\jstack.log perfectly works on the same machine. For the first time it took some time but again I executed with the redirect to file option, it completed with in few seconds.
This is an error message from the underlying O/S. There's not much you can do in your code to deal with this other than catch the exception which is thrown. Boo to Windows for being so limited.
http://technet.microsoft.com/en-us/library/cc978735.aspx