Re: [Wrapper-user] Wrapper under Solaris 64 bits

[Leif M. <le...@ta...>]

Alex,

Alexandre Morin wrote:

> Hi, I'm using the service wrapper under Solaris 9 (64 bits).
>
> First, I get this warning which, I guess is because the .so is 32bits (?)
>
> INFO | jvm 1 | 2005/03/23 17:38:03 | WARNING - Unable to load the
> Wrapper's native library 'libwrapper.so'.
>
> INFO | jvm 1 | 2005/03/23 17:38:03 | The file is located on the path
> at the following location but
>
> INFO | jvm 1 | 2005/03/23 17:38:03 | could not be loaded:
>
> INFO | jvm 1 | 2005/03/23 17:38:03 |
> /opt/InfoVista/VistaMart/wrapper/libwrapper.so
>
> INFO | jvm 1 | 2005/03/23 17:38:03 | Please verify that the file is
> readable by the current user
>
> INFO | jvm 1 | 2005/03/23 17:38:03 | and that the file has not been
> corrupted in any way.
>
> INFO | jvm 1 | 2005/03/23 17:38:03 | System signals will not be
> handled correctly.
>
As you guessed, this is being caused because you are running a 64-bit JVM
with a 32-bit JNI library. You will need to compile a 64-bit version of the
Wrapper and use that. The wrapper binary should be fine as 32-bit as it is
a separate process, but the library needs to match the JVM.

If you have the experience, I would appreciate it if you could try modifying
the Makefile.solaris file that ships with the source and coming up with a
Makefile.solaris64 which I can include in future releases of the Wrapper.

> But the problem is that it seem that it is not possible to use more
> than 4Gb of memory (values above get truncated down to 4Gb). Is there
> a workaround to go beyond the 4Gb limit?
>
The Wrapper is actually doing some error checking on the properties
right now.
If you use the wrapper.java.maxmemory property to set the memory then it is
being forced to a range of 1..4096 MB. I need to be checking whether the
version of the Wrapper is 32 or 64 bits. If it is the later, this can
obviously
be much larger.

For now, if you are using 3.1.0 or later, you can set the memory settings
as you would normally by omitting the wrapper.java.maxmemory property
and then using the following instead.
wrapper.java.additional.1=-Xmx6000m

Alternatively, if you are building from source (as above) Then you may just
want to increase the maximum range. Search for 4096 in the wrapper.c
source file. There are 2 places where the upper limit is being forced to
4096.

I don't have a system that I an try this on, so post back with the results.

Cheers,
Leif