Downgrading the severity to normal. I found a way around this problem

The jvm that was being used was a 1.5 JDK AMD64 build jvm.

When i try using the 1.5 i686 32 bit JVM and the RH9 or AS3 binary installers of
GT4.0.1 the java api's are working fine. I guess there must be a issue in how
the 64bit JVM loads 32 bit libraries.

The other problem on the unitialized handle still remains when using a 64 bit
jvm with a 64 bit build of globus buy its not critical for us atleast in the
short term anymore.

I believe we just need to update the flavors array that the Java portion of the
JNI client uses to load the RLS libraries.

Created an attachment (id=946) [details]
patch adds 64-bit flavors to RLSClient

After looking into the RLS Java client it is apparent that supporting 64-bit
platforms (java clients only) will require a bit more effort to make a good
clean fix. Presently, the RLS Java client was passing the address of allocated
memory as integer variables back and forth between the JNI C portion of the
client and the Java portion of the client. This was safe -- though not pretty
-- to do because the allocated memory was only being used by the JNI C portion
of the client (for reasons I won't go into, the C code needed to give the Java
code the address so that it could pass it back to the C code at a later time
when the memory was to be used).

At the time the code was written, the author chose to pass these memory
addresses as integers (4-byte architecture dependent data types). With 64-bit
platforms, these addresses (pointer data types) are now 8-bytes and the integer
data type no longer holds the complete address.

There is no simple way to pass a C-style pointer (memory address) back and
forth between Java and native code. Thus, fixing the existing JNI C portion of
the client is non-trivial. One way to fix this issue would be to stop passing
the memory address back to the Java code, perhaps by maintaining a list or
hashtable of the pointers and only passing an integer index into the
list/hashtable back to the Java code.

For now, we are going to provide two workarounds to this issue, though we are
not yet providing a permanent fix:

1. Use 32-bit clients on your otherwise 64-bit environment

Install GT with gcc64thr flavor, then install just the globus_rls_client
package again with gcc32thr flavor (you can install multiple flavors of GPT
packaged software such as RLS). Use a 32-bit JVM to run your Java RLS client
(in other words, to run your application that in turn uses the Java RLS
client). RLS clients and servers can interoperate whether 32-bit or 64-bit
client/server is on either side of the interaction.

2. Apply a couple patches attached to this record

These patches make the trivial change from casting the pointers in the JNI C
portion of the code to "jlong" data type instead of "int". This is essentially
equivalent to the current approach but with the 8-byte data type. I have tested
these patches on 32-bit platform and 64-bit platform installations.

"Why are you not providing a permenant fix yet?"

The patches provided essentially "fix" the problem with the same level of
quality as the original code. However, since this isn't really the right
solution, we prefer not to commit the fix to our repository (at this time),
especially since 32-bit users will now encounter a number of compiler warnings
that previously would not have been generated.

We have a few competing priorities, one of which (a pure Java client) would
make fixing this bug irrelevant.

Created an attachment (id=967) [details]
Part 1: Patch to RLSClient.java

From .../source-trees-thr/replica/rls/client, use:

% patch -p0 < RLSClient.java.diff

Created an attachment (id=968) [details]
Part 2: Patch to jni.c

From .../source-trees-thr/replica/rls/client, use:

% patch -p0 < jni.c.diff

***IMPORTANT***

The patches (created 2006-05-30) come from diffs to the globus_4_0_branch as of
the GT 4.0.2 release. Given that interface changes are not allowed to the
globus_4_0_branch, these patches will work on any future (and probably past) GT
4.0.x release of source.

However, the patches are not guaranteed to work with GT 4.1+ source, though
they *probably* do and *probably* will.

*** Bug 5133 has been marked as a duplicate of this bug. ***

A new RLS java client has been developed. Unlike the existing client that uses
JNI and only wraps the C client, the new client is written entirely in Java and
depends only on the Java CoG kit distributed with Globus. Also, the new client
is backward compatible with the existing Java client, so you can drop it in and
immediately start using it.

It can be found in the Globus CVS (trunk only) at:

replica/rls/client/java/source

The following GPT packages may be used to install the client.

For users of Globus Toolkit 4.0.x, use the following package:

http://www.isi.edu/~schuler/bug4114/4_0_x/globus_rls_client_java-0.0.tar.gz

For users of Globus Toolkit 4.1.x (development), use the following package:

http://www.isi.edu/~schuler/bug4114/dev/globus_rls_client_java-0.0.tar.gz

With either package, use the following command to install it:

$GPT_LOCATION/sbin/gpt-build globus_rls_client_java-0.0.tar.gz

The dev package will be released with the GT 4.2 release. We are looking into
releasing the 4.0.x package (perhaps as an advisory release).

Finally, we would like to thank the Pegasus project's Gaurang Mehta and Karan
Vahi for their help in testing the client.