Veda N Ponnusamy wrote:
Hi,
   We set the LD_ASSUME_KERNEL=2.2.5 and the hang goes away. But the application
 is running at 60% speed !!

Interesting. You could try LD_ASSUME_KERNEL=2.4.1 (the floating
stack version of LinuxThreads), it's generally faster than 2.2.5.

 Do you know any patches anywhere for this problem ???

Unfortunately, no, Redhat did not release the patch. RH9 is the
only platform we've seen this problem. We didn't stress test
Fedora Core, but AS-3 works Ok.

thanks,
-hui

P.S. Next time when you see the hang, please try the gdb trick
to id the bug. If the process still hangs after attach-detach
with gdb, it's something else.


Reg Veda


-----Original Message----- From: Hui Huang [mailto:[EMAIL PROTECTED] Sent: Thursday, June 24, 2004 10:39 AM To: Joseph Shraibman Cc: [EMAIL PROTECTED]; Veda N Ponnusamy; [EMAIL PROTECTED] Subject: Re: Help on JVM hang


Is this on Redhat 9? If so, try this:

+ find out java process id
+ use gdb to attach to the process (gdb - <pid>)
+ quit gdb

wait a few seconds, does the process start to run again? If yes,
it's a known RH-9 issue (a notification from pthread_cond_broadcast
is lost in NPTL). Update to AS-3 or set LD_ASSUME_KENREL should
fix it.

regards,
-hui

Joseph Shraibman wrote:

Just got another hang:

"RMI TCP Connection(5752)-199.107.233.207" daemon prio=1 tid=0x08243e08 nid=0x2420 waiting on condition [4e601000..4e602854]
at java.util.zip.Inflater.inflate(Inflater.java:219)
- waiting to lock <0x46292948> (a java.util.zip.Inflater)
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:128)
at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:408)
at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:450)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:182)
- locked <0x46317cd8> (a java.io.InputStreamReader)
at java.io.InputStreamReader.read(InputStreamReader.java:167)
at java.io.BufferedReader.fill(BufferedReader.java:136)
at java.io.BufferedReader.readLine(BufferedReader.java:299)
- locked <0x46317cd8> (a java.io.InputStreamReader)
at java.io.BufferedReader.readLine(BufferedReader.java:362)
at org.apache.xerces.util.ObjectFactory.findJarServiceProvider(Unknown Source)
at org.apache.xerces.util.ObjectFactory.createObject(Unknown Source)
at org.apache.xerces.util.ObjectFactory.createObject(Unknown Source)
at org.apache.xerces.parsers.DOMParser.<init>(Unknown Source)
at org.apache.xerces.parsers.DOMParser.<init>(Unknown Source)



Joseph Shraibman wrote:


Kinda looks like what happened to me. A lot of threads "waiting on condition" for no reason at all. For example:

"Thread-206" prio=1 tid=0x087b7d18 nid=0x7b88 waiting on condition [6e01e000..6e01f854]
at java.util.Stack.pop(Stack.java:59)
at org.apache.log4j.NDC.pop(NDC.java:274)


... and Stack.java looks like:

   public synchronized Object pop() {
       Object  obj;
       int     len = size(); //<===== line 59

       obj = peek();
       removeElementAt(len - 1);

       return obj;
   }

Veda N Ponnusamy wrote:


Please find attached the thread dump of the JVM. I didn't try running this app on 1.5 jvm

Reg
Veda


-----Original Message----- From: Joseph Shraibman [mailto:[EMAIL PROTECTED] Sent: Friday, June 11, 2004 1:26 PM To: Calvin Austin Cc: Veda N Ponnusamy; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Help on JVM hang


Calvin Austin wrote:


Does it ever resume. 1.5beta2 has more diagnostics in it and you may be able to even attached with jdb (hey tim :*)

Without seeing the other threads its difficult to see what is happening, however there was a bug fix in 1.5 to stop the cache growing out of control. A quick test with 1.5 would help a great deal.


I was never able to reproduce the hang on a test machine, it only happened in production under load. My boss would kill me if I ran a beta jvm in production.


I also haven't seen the bug for a couple of weeks since I limited the work done by that jvm in order to avoid the bug. And I'm not going to risk freezing our system in order to hit the bug again.


If I did attach to the jvm with jdb, what good would it do? What would I see that the SIGQUIT thread dump wouldn't show?




----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



---------------------------------------------------------------------- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]






----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Reply via email to