Bug 2683 - rft client never terminates even after transfer is complete
: rft client never terminates even after transfer is complete
Status: RESOLVED
: RFT
RFT
: 3.9.4
: IA64 Linux
: P3 normal
: ---
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2005-02-02 16:32 by
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


Note

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


Description From 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 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 2005-02-02 17:05:59 -------
Created an attachment (id=500) [details]
kill -QUIT <master_java_process>
------- Comment #3 From 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 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 2005-02-02 18:23:10 -------
Yes, the server side is the one I'm really interested in.
------- Comment #6 From 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 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 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 2005-02-07 18:07:09 -------
Will it be possible for me to try 3.9.5 on this platform ?
------- Comment #10 From 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 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 2005-02-15 09:13:23 -------
No. you don't have to redeploy gt every time you deploy a new jdk. 
------- Comment #13 From 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 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.