Currently I am facing application (JAVA RMI based) hang situation and RMI client GUI become Black.
In the application log does not record any exception and client / server communication has completely stopped at one stage. Once user restart the application it will resume the operations.
Initially we thought it was due to a JVM issue since we saw a dump file during this hang situation. This Dump file was not able to open or copy during this time, it is disappearing once we closed the application. We re-installed the JVM but this issue still hits intermittently.
We noticed this issue started few months after the production cutover and we did not come across during our testing and the initial few months of live cutover.
Application background
-RMI client/server based compiled on java 1.7_55
-OS (client Win7 32 bit & Server Win 2008 32 bit data centre), Win2008 runs on VMWare
-DB MSSql server 2008
It would be great if someone can advice me on this.
Thanks and Regards
Chamantha
Related
I am working with a ubuntu web server, where I have tomcat 8 and running a web application on tomcat. Recently I have faced some problem with cpu uses 100%. When I restart the tomcat server it is running good, but after one day or a few hour again same problem arise ( 100% cpu use) and that problem make my site slow. When I see the process list with htop command then i see so many process like
/opt/java8/jre/bin/java -Djava.util.logging.config.file=/opt/tomcat8/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoader
The website is a live eCommerce website and average user in every moment is around 100.
The server is a aws ec2 server where a tomcat and a java application inside the tomcat is running. The database (MySql) is in an another aws RDS server.
What can i do in this situation? Please help.
Problem Description
Hi everyone,
I was having problems remote debugging to a new server today and it initially appeared as if Eclipse was taking a long time to connect to a remote JVM. However, after some investigation I realized jdb was having a similar problem. Some digging turned up this...
Connecting to the remote JVM is not a problem. Both debuggers establish the socket connection properly within a few seconds. jdb even processes commands. However, after a remote debugger has connected to it successfully, the Sun Java 1.7.0_60-b19 JVM appears to be hanging (or transmitting extremely slowly) when sending its thread debugging information (JVMTI/JDWP) across the network via TCPIP.
Listing the remote JVM's threads appears to be the problem. JDB's threads command either hangs or executes extremely slowly. The load on the remote JVM is reasonable, and there aren't any breakpoints set. There are many threads executing on this JVM concurrently (~2005 threads), and there may be some WAN latency, but there still needs to be a way to successfully use a remote debugger with it!
Observation. I'm guessing this is related to inefficient transmission of thread information via TCPIP by the JVM's Java Debug Wire Protocol (JDWP) implementation, as the machine is on the other side of the planet on a WAN. HOWEVER -- Windows Remote Desktop Connection to the same machine is acceptably fast and performant. Given that, it seems that having to wait 45 minutes for Eclipse or JDB to list thread information on a JVM is unacceptable and likely a bug (or a very poorly implemented feature).
Possibly related to?
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6401245 - This
looks like it was fixed and shouldn't be the issue anymore. Plus the JVM is running on Windows Datacenter not Linux.
http://www.eclipsecon.org/2013/comment/reply/1153.html - Possible
solution but requires the SAP JVM?
https://github.com/vpotapev/jbreakpoint - Open source jdb interface
but doesn't fix issue with Eclipse.
Question. Does anyone have any ideas how to make the thread data transmission more efficient so the JVM can be remote debugged effectively? Is this a bug in the JVM's Java Debugging Wire Protocol (JDWP)?
Problem Details
Java Version:
C:\Users\Administrator>"C:\Program Files\Java\jdk1.7.0_60\bin\java" -version
java version "1.7.0_60"
Java(TM) SE Runtime Environment (build 1.7.0_60-b19)
Java HotSpot(TM) 64-Bit Server VM (build 24.60-b09, mixed mode)
Application Server. Happens with Weblogic 10g. Also happens with IBM WebSphere 8.5
Eclipse. Eclipse remote debugging hangs indefinitely when trying to populate the Debug view with thread information.
JDB - Remote. Java's jdb remote debugger hangs for upwards of 10 minutes when listing the threads with the thread command. Then it lists them VERY slowly (1 thread per second, would take 33 minutes to list them all).
"C:\Program Files\Java\jdk1.7.0_60\bin\jdb.exe -connect com.sun.jdi.SocketAttach:hostname=xxx.yyy.com,port=7777
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
Initializing jdb ...
> threads
Group system: <<jdb hangs here trying to get thread information>>
JDB - Local. Java's jdb remote debugger executes the threads command in 3 seconds when run on the JVM's local machine.
"C:\Program Files\Java\jdk1.7.0_60\bin\jdb.exe -connect com.sun.jdi.SocketAttach:hostname=xxx.yyy.com,port=7777
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
Initializing jdb ...
> threads
Group system:
> threads
Group system:
(java.lang.ref.Reference$ReferenceHandler)0x7484 Reference Handler
(java.lang.ref.Finalizer$FinalizerThread)0x7485 Finalizer
(java.lang.Thread)0x7486 ...
GC Daemon
(java.lang.Thread)0x748b RMI RenewClean-
...
>
After some investigation and packet sniffing, it appears that having a large number of threads in the remote process causes debugging packet congestion as well as a feedback loop of processing delays between the remote process debug agent and the remote debugger. Basically, the JVM debugging agent isn't engineered for high latency connections or debugging a large number of threads remotely. It also doesn't make an attempt to compress thread/stack/variable update information to lower transfer time to the debugger.
Our solution was eventually to add a thread debug mode to our product that reduced the various server thread pool sizes, then debugging was suddenly acceptably responsive again across overseas networks.
A future suggestion to the Java community would be to add a thread filter feature to both Eclipse and the Java Debug Agent so that only information for threads of interest is transmitted to the debugger after each code step is signalled.
I used visualvm last week on my notebook and it worked without any issues. When I wanted to use it yesterday I get the error: VisualVM Cannot connect to 178.xxx.xxx.xxx:xxxx using service:jmx:rmi///... once adding a jmx connection.
The odd thing here is that I have the same version of visualvm, java jdk, java security level, internet connection and windows 7 professional on the desktop computer where it still works.
firewall disabled (didn't work)
port forwarding (not needed as it works fine on the desktop computer with the same connection)
additional firewalls or anti virus software is not present
The notebook is a dell and a few days ago it got a major bios and dell util update, but I don't think this should fall into account in this matter.
Do you have any idea what else it could be, or what else I could do to track down the issue?
FYI I have another WIN7 home computer where it still works and a partner reported that he is getting the same issue for some time now on his desktop and notebook. I'm really at the end of my expertise :(
Seems like network environment issue. You may trace the other port first. (like 80 port)
I know this sounds like a generic question, but I need some guidance.
We have a distributed system with Java swing client, Glassfish 3.0.1 as application server and PostgreSQL as database. We are using hessian protocol for communication with the Glassfish 3.0.1 server.
There are around 5 users using the client simultaneously. Everything is running fine, until all users say that their client stops responding for 10 seconds and then it continues to run fine for 15 minutes for example. And then the same thing happens. When I restart the server they say it is fine, but after half a day, again the same thing happens. I looked at the database logs, and I don't see queries above 1 second. I think the problem is connected with the communication to the Glassfish server(all clients cannot communicate to the server at the same time).
How could I approach the problem?
P.S When glassfish stops responding, I can't even open the index.html page properly.
Greetings,
Petar
when try to execute the servlet containing following code
Runtime rt = Runtime.getRuntime();
Process p = rt.exec("notepad.exe");
It doesn't launch the application in the environment windows server 2003 and Tomcat 5
but a process is being created as notepad.exe in the windows task manager.
In windows xp and tomcat 6 environment launches the notepad
i need to work on the windows server 2003 and tomcat 5
Thanks in advance
In other words, it get launched on your local development machine (WinXP + Tomcat6), but not at a production/test server (Win2K3 + Tomcat5)?
Do you realize that Java Servlet code runs at the server machine, not at the client machine, which are in real world usually two physically different machines connected by a network? The notepad is opened at the server machine (there where the webserver (Tomcat) runs), not at the client machine (there where the webbrowser runs). That it works at local development environment is just because both the webserver and webbrowser runs at the physically same machine.
Login to your Win2K3 environment and you'll see that notepad is opened there.
If you really intend to launch notepad.exe at the client machine using Runtime#exec() (I don't see any business reasons for this, but that aside), then you'll need to provide the client a Java application in flavor of an Applet or Web Start Application served by a HTML/JSP page. This will get downloaded to the client machine and will be executed there.
If you could tell us the requirement to launch notepad.exe, then we could suggest a solution/approach to you.
I think your tomcat runs as a service at the background. When running notepad it is executed with the same logon that your tomcat runs with. Most likely thats a different logon than your desktop-logon and thus the notepad won't be displayed at that desktop!
In your dev environment you started tomcat by executing the wrapper scripts directly. Try to install it as a service and you will get the same problems with XP.
Btw: I don't see a point in running an AppServer and calling notpad at the server. Are you really sure about the design?