Bug 2683 – rft client never terminates even after transfer is complete

Bug 2683 - rft client never terminates even after transfer is complete

Summary:

rft client never terminates even after transfer is complete

Status:	RESOLVED

Product:	RFT
Component:	RFT
Version:	3.9.4
Platform:	IA64 Linux

Importance:	P3 normal
Target Milestone:	---
Assigned To:	Ravi Madduri

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2005-02-02 16:32 by John-Paul Navarro
Modified:	2005-02-18 11:36 (History)

Attachments
kill -QUIT <master_java_process> (5.24 KB, text/plain) 2005-02-02 17:05, John-Paul Navarro	Details
Server kill -QUIT javacore...txt (362.08 KB, text/plain) 2005-02-03 10:05, John-Paul Navarro	Details
Client kill -QUIT corresponding to previous server attachment (4.21 KB, text/plain) 2005-02-03 10:15, John-Paul Navarro	Details
Add an attachment (proposed patch, testcase, etc.)

Note

You need to log in before you can comment on or make changes to this bug.

Description From John-Paul Navarro 2005-02-02 16:32:09

When I run the GT 3.9.4 rft client on SLES8/IA-64 using IBM's Java2 1.4.2
the client doesn't display the usual progress to stdout and never terminates
even though the transfers do complete. An identical build on SLES8/IA-32
also using IBM's Java2 1.4.2 behaves normally.  IBM's Java is apparantly based
on Sun's Java. Sun Java2 1.4.2_07 has the same problem.In the very likely scenario
that this is a Java problem, is their any chance you could isolate the broken
behavious so we can report the problem to Sun and/or IBM?   Thanks.

------- Comment #1 From Jarek Gawor 2005-02-02 16:51:58 -------

When things appear hung, can you please issue kill -QUIT <jvm process> for the 
client and server process? That will cause the JVM the dump its threads (to 
stdout/err). Can you capture that output and send it to us.

------- Comment #2 From John-Paul Navarro 2005-02-02 17:05:59 -------

Created an attachment (id=500) [details]
kill -QUIT <master_java_process>

------- Comment #3 From John-Paul Navarro 2005-02-02 17:06:57 -------

Is the thread dump for the client enough, or do you really need the server side
too?

------- Comment #4 From John-Paul Navarro 2005-02-02 17:08:14 -------

You'll notice in the log two different transfers. The first one worked, which
really
surprised me because it's the first time I've seen it work on IA-64 (~4
previous tries).
The second rft hung as expected.

------- Comment #5 From Jarek Gawor 2005-02-02 18:23:10 -------

Yes, the server side is the one I'm really interested in.

------- Comment #6 From John-Paul Navarro 2005-02-03 10:05:22 -------

Created an attachment (id=502) [details]
Server kill -QUIT javacore...txt

This server is running on SLES8 IA-32 which is different than the hanging
client which is SLES8 IA-64.

------- Comment #7 From John-Paul Navarro 2005-02-03 10:15:06 -------

Created an attachment (id=503) [details]
Client kill -QUIT corresponding to previous server attachment

This client kill -QUIT corresponding to server javacore attachment 502 [details].
This is a SLES8 IA-64 client.

------- Comment #8 From Jarek Gawor 2005-02-07 00:34:28 -------

The logs look good to me... so it might be some issue in RFT or dependent code 
related to the JVM.

------- Comment #9 From Ravi Madduri 2005-02-07 18:07:09 -------

Will it be possible for me to try 3.9.5 on this platform ?

------- Comment #10 From John-Paul Navarro 2005-02-08 09:49:42 -------

If this question was for me.  I'll install 3.9.5 as soon as it's released.  You
can also install any version 
you'd like in your home directory. JP

------- Comment #11 From John-Paul Navarro 2005-02-14 11:17:05 -------

We've tested all of the following Java's with identical results:
- IBM Java2 1.4.2 build cxia64142-20040917
- Sun Java2 1.4.2_07
- Bea JRockit 1.4.2_05
- Bea JRockit 1.5.0
Once GT 3.9.x is deployed using a specific Java, is it OK for me to switch at runtime which Java
is used by the RFT client, for example, or do I need to re-deploy GT 3.9.x using every Java I
want to use/test?

------- Comment #12 From Ravi Madduri 2005-02-15 09:13:23 -------

No. you don't have to redeploy gt every time you deploy a new jdk.

------- Comment #13 From Ravi Madduri 2005-02-18 11:31:40 -------

Turns out it was a networking configuration issue and not an acrchitecture
issue. If JP can add more 
details, i can close the bug

------- Comment #14 From John-Paul Navarro 2005-02-18 11:36:17 -------

Looks like this was a host misconfiguration problem.  The failing IA-64 machine
had
a bad IP address for itself in /etc/hosts. Admin error.