|
From: Leif M. <lei...@ta...> - 2012-07-19 17:26:37
|
Gustaf, Please see the ping timeout documentation for a description of how this is working. http://wrapper.tanukisoftware.com/doc/english/prop-ping-timeout.html Also this: http://wrapper.tanukisoftware.com/doc/english/qna-freeze.html Try setting the ping timeout to a long value like 5 minutes. If that makes the problem go away then it is a temporary freeze. If it is still being restarted however, then your JVM is actually freezing and the Wrapper is doing its job correctly. If you find that it is a temporary freeze, you need to figure out what is causing the JVM to become unresponsive for so long. The default ping timeout is 30 seconds, which is a long time for the JVM to be stuck. One common cause of long freezes is if the JVM is being swapped to disk due to other applications consuming all available memory. We are constantly making improvements to the Wrapper. 3.2.3 was released way back in 2006. There have been a LOT of improvements since then. Both in features, and in performance and improvements. I would suggest that you give a newer version a try. As the warning in the log is clearly stating, you are not successfully reading in the wrapper.dll file. This is not in any way the cause of your current problem. But there are several features which will not be working without the DLL. We have added a new feature to the upcoming 3.5.16 release which will make this particular issue easier to track down by requesting that the Wrapper log a warning whenever a ping is slower than a configured threshold. It will be possible to set that to 5 seconds, but the actual timeout to 5 minutes for example so you can let it run for a few days and see how often, and for how long, you are having temporary freezes. Cheers, Leif On Fri, Jul 20, 2012 at 12:41 AM, Gustaf Cele <gus...@da...>wrote: > We’re running a JBoss server as a service under Windows using the Java > Service Wrapper. For most of the time, JBoss runs fine. But… we’ve been > experiencing some problems: When we run some heavy, long-running jobs, the > wrapper sometimes decides to restart the JVM:**** > > ** ** > > ERROR | wrapper | 2012/07/19 13:11:19 | JVM appears hung: Timed out > waiting for signal from JVM.**** > > ERROR | wrapper | 2012/07/19 13:11:19 | JVM did not exit on request, > terminated**** > > STATUS | wrapper | 2012/07/19 13:11:24 | Launching a JVM...**** > > INFO | jvm 3 | 2012/07/19 13:11:24 | Wrapper (Version 3.2.3) > http://wrapper.tanukisoftware.org**** > > INFO | jvm 3 | 2012/07/19 13:11:24 | Copyright 1999-2006 Tanuki > Software, Inc. All Rights Reserved.**** > > INFO | jvm 3 | 2012/07/19 13:11:24 |**** > > INFO | jvm 3 | 2012/07/19 13:11:24 |**** > > INFO | jvm 3 | 2012/07/19 13:11:24 | WARNING - Unable to load the > Wrapper's native library 'wrapper.dll'.**** > > INFO | jvm 3 | 2012/07/19 13:11:24 | The file is located on > the path at the following location but**** > > INFO | jvm 3 | 2012/07/19 13:11:24 | could not be loaded:** > ** > > INFO | jvm 3 | 2012/07/19 13:11:24 | C:\Path\to\jboss\ > 4.2.2.GA\lib\wrapper.dll**** > > INFO | jvm 3 | 2012/07/19 13:11:24 | Please verify that the > file is readable by the current user**** > > INFO | jvm 3 | 2012/07/19 13:11:24 | and that the file has > not been corrupted in any way.**** > > INFO | jvm 3 | 2012/07/19 13:11:24 | One common cause of > this problem is running a 32-bit version**** > > INFO | jvm 3 | 2012/07/19 13:11:24 | of the Wrapper with a > 64-bit version of Java, or vica versa.**** > > INFO | jvm 3 | 2012/07/19 13:11:24 | This is a 64-bit JVM.* > *** > > INFO | jvm 3 | 2012/07/19 13:11:24 | Reported cause:**** > > INFO | jvm 3 | 2012/07/19 13:11:24 | C:\Path\to\jboss\ > 4.2.2.GA\lib\wrapper.dll: Can't load IA 32-bit .dll on a AMD 64-bit > platform**** > > INFO | jvm 3 | 2012/07/19 13:11:24 | System signals will > not be handled correctly.**** > > ** ** > > Yes, we are totally going to upgrade to the 64-bit version of the wrapper, > but as previously stated - JBoss works fine except sometimes during the > long, heavy jobs (the JVM restart happens for approximately one in six > jobs). We’re wondering what could cause this behavior.**** > > ** ** > > - If our process is running at 100% CPU, how likely is it that the process > won’t respond to the wrapper’s pings in due time (30 seconds)?**** > > - Could the incompatible 32-bit wrapper.dll have something to do with our > woes?**** > > ** ** > > It may also be relevant say to that this started happening a fairly short > while ago, and didn’t coincide with any changes to the setup (that we can > think of, anyway). The same setup had been running happily for quite some > time before, in spite of the incompatible DLL and the long-running CPU hogs. > **** > > ** ** > > Thanks in advance, **** > > ** ** > > /g**** > > |