Re: [Wrapper-user] Environment problems?

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

Eric,
The Wrapper opens a single socket that accepts connections from the JVM
when the WrapperManager class initializes.  This socket is then used for
all communication between the Wrapper and the JVM.  You might want to
try changing the value of wrapper.port to another value and see if that
changes anything.   It is a TCP connection, and your bus transport  uses
UDP, so I doubt that is the problem.

The next thing I would suggest trying is to copy the entire command used
to launch the Java process into a shell script and try running the exact
same command.  This is an easy way to eliminate the Wrapper as the
cause of your problems.   It will still use the WrapperManager within the
JVM but in my experience, there has never been a problem that I heard
about caused by that class being loaded.
You do need to make one change to the command line from that shown
in the debug output of the wrapper.  remove the wrapper.key property.
If it is defined, then the WrapperManager class will think it is supposed
to be communicating with the Wrapper and will exit the JVM when it fails
to do so.  Otherwise there should be no changes.

I will be interested to see if your application works or fails there.

It is possible that your application may be loading native libraries.
Normally most java applications do not specify a java library path, so
the JVM will use the default.  In the case of the wrapper, you must specify
the location of the libwrapper.so file on in the wrapper.conf file.  This
means that the default library path will not be searched.  To fix this you
would need to add the location of the additional libraries as additional
library path entries in the wrapper.conf file.  If this is the problem, then
the above test should fail.

Cheers,
Leif


Roberts, Eric wrote:

>Leif,
>
>Firstly thanks for the response.
>
>The application is third party (Tibco Integration Manager), so I can only give you a rough idea of what is taking place.
>
>The program is designed to be fault tolerant - the first "engine" is started with a flag which tells it to establish a fault tolerant bus transport, subsequent "engines" search for existing engines with the same group name and form a fault tolerant cluster. The exception is occurring when the first instance attempts to establish the fault tolerant bus transport (hence the error message "Initialization failed for bus transport FtDefault"). I believe that this transport is UDP.
>
>Because I can successfully start the program from the command line, I thought at first to ask about how the wrapper passed environment settings. From your response it would appear that the environment is not the issue.
>
>Do you think that there could be some system resource conflict between the wrapper, and the application trying to establish the transport?
>
>Another thought was permissions - but again, if I can run the program successfully from the same shell as I try to run the wrapper, then I cannot see that this could be an issue.
>
>I hope that some genius out there might be able to hint at what the problem might be and a possible fix, as I currently have many of these programs to support in a production environment, and the wrapper seemed the perfect solution for automatic restarting.
>
>Regards
>
>Eric
>  
>