wrapper-user — User issues for Wrapper. (Support questions, etc.)

Re: [Wrapper-user] HP-UX 11i 64 bit:log level DEBUG crashes application

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

Venkatesh,
    Ok, I think I know what the problem is.  I found this message:
http://lists.parisc-linux.org/pipermail/parisc-linux/2004-March/022504.html

    It comments on the EWOULDBLOCK and EAGAIN constants not being
equal on HPUX like they are on Linux.   I am testing for EWOULDBLOCK,
but reviewing the accept man page, it looks like I should be testing for 
EAGAIN.

    Could try out a couple more changes to the code and let me know how they
work out?

    The first is to modify the tests just after the accept call on or 
about wrapper.c:552
Old:
---
    if (sd == INVALID_SOCKET) {
        rc = wrapperGetLastError();
        if (rc == EWOULDBLOCK) {
            /* There are no incomming sockets right now. */
            return;
        } else {
            if (wrapperData->isDebugging) {
                log_printf(WRAPPER_SOURCE_PROTOCOL, LEVEL_DEBUG,
                    "socket creation failed. (%s)", getLastErrorText());
            }
            return;
        }
    }
---
New:
---
    if (sd == INVALID_SOCKET) {
        rc = wrapperGetLastError();
        log_printf(WRAPPER_SOURCE_PROTOCOL, LEVEL_DEBUG,
            "errno 11 = %s", strerror(11));
        log_printf(WRAPPER_SOURCE_PROTOCOL, LEVEL_DEBUG,
            "errno EWOULDBLOCK = %d = %s", EWOULDBLOCK, 
strerror(EWOULDBLOCK));
        log_printf(WRAPPER_SOURCE_PROTOCOL, LEVEL_DEBUG,
            "errno EAGAIN = %d = %s", EAGAIN, strerror(EAGAIN));
        /* EWOULDBLOCK != EAGAIN on some platforms. */
        if ((rc == EWOULDBLOCK) || (rc == EAGAIN)) {
            /* There are no incomming sockets right now. */
            return;
        } else {
            if (wrapperData->isDebugging) {
                log_printf(WRAPPER_SOURCE_PROTOCOL, LEVEL_DEBUG,
                    "socket creation failed. (%s)", getLastErrorText());
            }
            return;
        }
    }
---
I am expecting that EAGAIN = 11 on your system.   If not, then I would 
appreciate
it if you could figure out what constant is = 11 on your machine.   
Assuming for now
that it is, then the patch above and the one that follows should fix 
your problem.

The second patch is for the test just after the recv call at or around 
line 793.
Old:
---
        len = recv(sd, &c, 1, 0);
        if (len == SOCKET_ERROR) {
            err = wrapperGetLastError();
            if (wrapperData->isDebugging) {
                if ((err != EWOULDBLOCK) && (err != ENOTSOCK) && (err != 
ECONNRESET)) {
                    log_printf(WRAPPER_SOURCE_PROTOCOL, LEVEL_DEBUG,
                        "socket read failed. (%s)", getLastErrorText());
                    wrapperProtocolClose();
                }
            }
---
New:
---
        len = recv(sd, &c, 1, 0);
        if (len == SOCKET_ERROR) {
            err = wrapperGetLastError();
            if (wrapperData->isDebugging) {
                if ((err != EWOULDBLOCK) && (err != EAGAIN)
                    && (err != ENOTSOCK) && (err != ECONNRESET)) {
                    log_printf(WRAPPER_SOURCE_PROTOCOL, LEVEL_DEBUG,
                        "socket read failed. (%s)", getLastErrorText());
                    wrapperProtocolClose();
                }
            }
---

Cheers,
Leif

Venkatesh Sellappa wrote:

>Hi List,
>
>I think we got a little bit more visibility on this.
>Having made the changes to wrapper.c and re-compiling.
>I still get the same error.
>
>The value of EWOULDBLOCK in this case is not 11 but 246.
>
>I have mailed you the log file with all the gory details.
>
>Cheers,
>
>  
>
<snip>

[Wrapper-user] Re: Newbie - App Integration

[Nick R. <nic...@em...>]

Thanks for your reply Leif.

I'm running the app simply as "java Pserver.class" in the console. The
Pserver.java looks like:

import java.io.*;
import java.net.*;

public class Pserver {

    public static void main(String[] args) 
    {
        ServerSocket serverSocket;
        Socket client;
        Pthread thClient;

        try
        {

            serverSocket=new ServerSocket(39823);
            while(true)
            {
                client=serverSocket.accept();
                thClient = new Pthread(client);
                thClient.run();
            }

        }
        catch(Exception e)
        {
            e.printStackTrace();
        }
    }

}


Can u please give me an example on the above code, as to how to
implement the helper class and what configuration to use for the
wrapper. Maybe I am thinking too hard :)

Thanks for your help mate!



-------------------------------------


Nick,
     How are you running your application without the Wrapper?  If you 
 use method 1,
 with the WrapperSimpleApp helper class, there is zero special coding 
 that you will
 have to do.
     You simply specify your main class as the argument to the 
 WrapperSimpleApp
 helper class and you are up and running.
 
     It sounds like your Pserver and Pthread classes are both running in 
 the same
 JVM? Correct?   Post how you normally run them from a console and I"ll
 tell
 you what you need to do to use the Wrapper.   I have a feeling that you 
 are just
 thinking too hard :-)
 
 Cheers,
 Leif
 
 Nick Rice wrote:
 
 >Hello All,
 >
 >This wrapper is exactly what I"ve was looking for. But I need some help
 >on how to go about integrating it with my application. See, I have a two
 >java class files (say Pserver.class and Pthread.class). Pserver listens
 >as a server socket (i.e. in a while loop), and it passes the socket
 >client to the Pthread class which processes the incoming data. Now, in
 >this scenario, how can I go about integrating the Pserver as an
 >unmanaged service. I read the docs but I"m not sure which of the three
 >integration methods is most suitable in my case. I tried playing with
 >the first (simpler) integration method but due to my limited Java
 >knowledge I could not get it to run as a service. I guess what I"m
 >missing is hot to integrate the wrapper and my Pserver class. Can
 >someone provide more details on how to impelment the helper class in my
 >Pserver class and then finally where to specify the wrapper to use the
 >modified Pserver.
 >
 >Any help is much appreciated. Thanks :)
-- 
  Nick Rice
  nic...@em...

RE: [Wrapper-user] HP-UX 11i 64 bit:log level DEBUG crashes application

[Venkatesh S. <Ven...@lc...>]

++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Please read the disclaimer at the bottom of this e-mail.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Hi List,

I think we got a little bit more visibility on this.
Having made the changes to wrapper.c and re-compiling.
I still get the same error.

The value of EWOULDBLOCK in this case is not 11 but 246.

I have mailed you the log file with all the gory details.

Cheers,

-----Original Message-----
From: wra...@li...
[mailto:wra...@li...]On Behalf Of Leif
Mortenson
Sent: 30 June 2004 15:54
To: wra...@li...
Subject: Re: [Wrapper-user] HP-UX 11i 64 bit:log level DEBUG crashes
application


Venkatesh,
 From the logs you sent me I now understand what the problem is.  The=20
thing is, I
am not sure who you are encountering it.

In both the case where I accept the socket from the JVM and when I read=20
a packet,
there is a chance that there is no socket or no data.  In such cases, I=20
have the sockets
configured to be in nonblocking mode so the lack of data does not hang=20
things up.

In such cases, both the accept and recv functions set errno to=20
EWOULDBLK.  See
the following code where I test the error after attempt to accept a socket.

    if (sd =3D=3D INVALID_SOCKET) {
        rc =3D wrapperGetLastError();
        if (rc =3D=3D EWOULDBLOCK) {
            /* There are no incomming sockets right now. */
            return;
        } else {
            if (wrapperData->isDebugging) {
                log_printf(WRAPPER_SOURCE_PROTOCOL, LEVEL_DEBUG,
                    "socket creation failed. (%d)", rc);
            }
            return;
        }
    }

To avoid the debug error messages you are seeing on startup, I am=20
special casing
the EWOULDBLOCK code so that it silently fails.  Any other error will=20
display a
debug error message.

Now the strange part.   On your system, accept is setting errno to a=20
value of 11
when a socket is not available.   On Linux and every other system the=20
Wrapper
works on to date, EWOULDBLOCK =3D 11.

Since the above code is failing on your system, EWOULDBLOCK is obviously
not =3D 11 with your compiler.    Could you place the following lines of=20
code just
before the above code.

log_printf(WRAPPER_SOURCE_PROTOCOL, LEVEL_DEBUG,
    "errno 11 =3D %s", strerror(11));
log_printf(WRAPPER_SOURCE_PROTOCOL, LEVEL_DEBUG,
    "errno EWOULDBLOCK =3D %d =3D %s", EWOULDBLOCK, strerror(EWOULDBLOCK));

On linux, this prints out the following:
errno 11 =3D Resource temporarily unavailable
errno EWOULDBLOCK =3D 11 =3D Resource temporarily unavailable

Now on with the explanation...
In the case of accept, the above problem is simply causing an extra=20
debug message
to be printed out.   But after a socket is connected, the Wrapper reads=20
a packet
from the JVM immediately after it connects, but when it calls recv again=20
to see if
there are any more packets, recv returns that there is no data and sets=20
errno to 11.
Pretty much the same code fails to match this to EWOULDBLOCK and so
assumes that it is an unexpected socket error.   This leads to the=20
socket being
closed and the JVM being restarted as you are seeing.

So the cause of all your problems is the value of the EWOULDBLOCK constant
on your system.

Could you try recompiling the c source and make sure that there are no=20
warning
messages about this constant being undefined?  If the constant just has=20
a different
value on your system, then recv and accept should still be using the=20
constant and
returning that other value...

Cheers,
Leif

Leif Mortenson wrote:

> Venkatesh,
>    Sorry about the hassle getting your hands on a  64-bit build.   It=20
> sounds like there are
> actually several such users out there.  Not having access to any=20
> hardware however, I
> must rely on users willing to donate the time to maintain and build=20
> such releases.  We
> have someone for the 32-bit version, but not the 64-bit version yet. =20
> I have been
> hoping that there is a way to build both the 32-bit .so and 64-bit .sl=20
> file on the same
> machine so that they can both be shipped with the HP-UX distribution.
>
>    See the answers to your questions below.
>
> Venkatesh Sellappa wrote:
>
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Please read the disclaimer at the bottom of this e-mail.
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>> Hi All,
>>
>> Congratulations on building an excellent product.
>> It fills a very important need in the Java market.
>>
>> For our production environment we are using the following:
>> 0.HP-UX 11i ( 64 bit )
>> 1.Java 1.4.2_03
>> 2.Wrapper version 3.1.0
>>
>> In the absence of a 64-bit binary library and hitting the problems=20
>> discussed earlier in the mailing list,
>> with the 32-bit library.
>> Re:=20
>> http://sourceforge.net/mailarchive/forum.php?thread_id=3D3751203&forum_i=
d=3D11948=20
>>
>>
>> I used the cc,make and ld native to HP-UX to build the libwrapper.sl=20
>> library from source.(GNU utilities not being allowed).
>> The source files for building the library were=20
>> wrapperjni_unix.c,wrapperinfo.c,wrapperjni.c.
>>
>> On changing the properties
>> wrapper.console.loglevel=3DDEBUG
>> wrapper.logfile.loglevel=3DDEBUG
>> from INFO to DEBUG
>>
>> I hit the following,
>> DEBUG OUTPUT
>> ------------
>> STATUS | wrapper  | 2004/06/29 13:20:34 | --> Wrapper Started as Console
>> DEBUG  | wrapperp | 2004/06/29 13:20:34 | server listening on port=20
>> 32000.
>> ..
>> DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket creation failed. (11)
>> INFO   | jvm 1    | 2004/06/29 13:20:35 | Initializing...
>> DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket creation failed. (11)
>> ..
>> INFO   | jvm 1    | 2004/06/29 13:20:35 | Loaded native library:=20
>> libwrapper.so
>> INFO   | jvm 1    | 2004/06/29 13:20:35 | Calling native=20
>> initialization method.
>> INFO   | jvm 1    | 2004/06/29 13:20:35 | Inside native=20
>> WrapperManager initialization method
>> ..
>> INFO   | jvm 1    | 2004/06/29 13:20:35 |=20
>> WrapperManager.start(org.tanukisoftware.wrapper.test.Main@a981ca,=20
>> args[]) called by thread: main
>> ..
>> INFO   | jvm 1    | 2004/06/29 13:20:35 | Open socket to wrapper...
>> INFO   | jvm 1    | 2004/06/29 13:20:35 | Opened Socket
>> INFO   | jvm 1    | 2004/06/29 13:20:35 | Send a packet KEY :=20
>> HjjwQG4LdL3g_kNV
>> INFO   | jvm 1    | 2004/06/29 13:20:35 |=20
>> handleSocket(Socket[addr=3D/127.0.0.1,port=3D32000,localport=3D57670])
>> DEBUG  | wrapperp | 2004/06/29 13:20:35 | accepted a socket from=20
>> 127.0.0.1 on port 57670
>> ..
>> DEBUG  | wrapper  | 2004/06/29 13:20:35 | Start Application.
>> DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket creation failed. (11)
>> DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket not open, so packet=20
>> not sent START : start
>> ERROR  | wrapper  | 2004/06/29 13:20:35 | Unable to send the start=20
>> command to the JVM.
>> =20
>>
> Strange.  The JVM is opening its socket to the JVM.  The Wrapper=20
> appears to be
> correctly accepting the new socket, and trading keys correctly?(this=20
> part is clipped?).
> But then when the  wrapper attempts to tell the Java side app to=20
> start, it finds that the
> socket is no longer open.    I am wondering what happened in the=20
> region that is cut
> out.
>
>> ERROR  | wrapper  | 2004/06/29 13:20:35 | Sending the JVM process a=20
>> SIGTERM
>> ..
>> ERROR  | wrapper  | 2004/06/29 13:20:37 | Critical error: wait for=20
>> JVM process failed (No child processes)
>>
>> END DEBUG OUTPUT
>> ----------------
>> Note 1:It still says libwrapper.so loaded, even though there is no=20
>> libwrapper.so in the path, its libwrapper.sl
>> =20
>>
> The actual location and loading of the library is being handled by the=20
> JVM.   All I am
> able to do is to tell whether or not it was loaded.  Currently I=20
> always display a message
> that libwrapper.so was loaded, with the exceptions of Wrapper.dll for=20
> Windows and
> libwrapper.jnilib for OSX.   Until HP-UX, this has been correct for=20
> all other platforms.
>
> If you know of any System property values which I can use to=20
> distinguish between
> 32 and 64 bit versions then I can add a special case to correct this=20
> message.
> On Solaris, the same so file seems to be working for both 32 and 64=20
> bit versions of
> the OS.
>
>> Note 2:On changing the log level back to INFO from DEBUG it works fine
>> =20
>>
> This could be one of two things.  A timing issue.  The startup would=20
> be slightly faster
> without the debug output.   Or a corruption/synchronization problem=20
> caused by the
> debug output itself.
>
> You have debug output enabled both the console and file.  What happens=20
> if you only
> do one or the other?
>
>> Note 3:Using method 3 i integrated my application with the wrapper=20
>> and hit the exact same problem, if i keep the wrapper loglevel at=20
>> INFO and my application loglevel at DEBUG( using log4j )it works fine.
>> Note 4:The debug output has been truncated to make it a bit more=20
>> readable, i can send the full log if required.
>> =20
>>
> Could you send the full log file to me directly?   Keep all other=20
> messages on
> list please.  Also send along your wrapper.conf file.   tar.gz them=20
> both up
> before sending them off to make sure that the text attachments don't get
> reformated or anything.
>
> Recreate the log using the following:
>
> wrapper.console.loglevel=3DDEBUG
> wrapper.logfile.loglevel=3DDEBUG
> wrapper.state_output=3DTRUE
>
> The state output causes the main event loop to dump a message for each=20
> cycle.  The
> log output goes way up, but it may help pit down the exact timing of=20
> what is
> happening.
>
>> What other diagnostics can i run to narrow down the problem ?
>> =20
>>
> Let me take a look at the log and I may have some more questions.
>
> Cheers,
> Leif


**********************************************************************
This email is intended for the named recipient(s) only. Its contents
are  confidential and may only be retained by the named recipient(s)
and may only be copied or  disclosed  with the consent of=20
LCH.Clearnet Limited.   If you are not an intended recipient please
delete this e-mail and notify pos...@lc....

The contents  of this  email are  subject to  contract in all cases,=20
and LCH.Clearnet Limited makes no contractual commitment save where
confirmed by hard copy.  LCH.Clearnet Limited accepts no liability,=20
including liability for negligence, in respect of any statement in=20
this email.

LCH.Clearnet Limited, Registered Office: Aldgate House,=20
33 Aldgate High Street, London EC3N 1EA.    Recognised as a Clearing=20
House under the Financial Services & Markets Act 2000. Reg in England No.25=
932=20
Telephone: +44 20 7426 7000              Internet: http://www.lchclearnet.c=
om
**********************************************************************

Re: [Wrapper-user] Newbie - App Integration

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

Nick,
    How are you running your application without the Wrapper?  If you 
use method 1,
with the WrapperSimpleApp helper class, there is zero special coding 
that you will
have to do.
    You simply specify your main class as the argument to the 
WrapperSimpleApp
helper class and you are up and running.

    It sounds like your Pserver and Pthread classes are both running in 
the same
JVM? Correct?   Post how you normally run them from a console and I'll tell
you what you need to do to use the Wrapper.   I have a feeling that you 
are just
thinking too hard :-)

Cheers,
Leif

Nick Rice wrote:

>Hello All,
>
>This wrapper is exactly what I've was looking for. But I need some help
>on how to go about integrating it with my application. See, I have a two
>java class files (say Pserver.class and Pthread.class). Pserver listens
>as a server socket (i.e. in a while loop), and it passes the socket
>client to the Pthread class which processes the incoming data. Now, in
>this scenario, how can I go about integrating the Pserver as an
>unmanaged service. I read the docs but I'm not sure which of the three
>integration methods is most suitable in my case. I tried playing with
>the first (simpler) integration method but due to my limited Java
>knowledge I could not get it to run as a service. I guess what I'm
>missing is hot to integrate the wrapper and my Pserver class. Can
>someone provide more details on how to impelment the helper class in my
>Pserver class and then finally where to specify the wrapper to use the
>modified Pserver.
>
>Any help is much appreciated. Thanks :)
>  
>

[Wrapper-user] Newbie - App Integration

[Nick R. <nic...@em...>]

Hello All,

This wrapper is exactly what I've was looking for. But I need some help
on how to go about integrating it with my application. See, I have a two
java class files (say Pserver.class and Pthread.class). Pserver listens
as a server socket (i.e. in a while loop), and it passes the socket
client to the Pthread class which processes the incoming data. Now, in
this scenario, how can I go about integrating the Pserver as an
unmanaged service. I read the docs but I'm not sure which of the three
integration methods is most suitable in my case. I tried playing with
the first (simpler) integration method but due to my limited Java
knowledge I could not get it to run as a service. I guess what I'm
missing is hot to integrate the wrapper and my Pserver class. Can
someone provide more details on how to impelment the helper class in my
Pserver class and then finally where to specify the wrapper to use the
modified Pserver.

Any help is much appreciated. Thanks :)
-- 
  Nick Rice
  nic...@em...

Re: [Wrapper-user] HP-UX 11i 64 bit:log level DEBUG crashes application

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

Venkatesh,
 From the logs you sent me I now understand what the problem is.  The 
thing is, I
am not sure who you are encountering it.

In both the case where I accept the socket from the JVM and when I read 
a packet,
there is a chance that there is no socket or no data.  In such cases, I 
have the sockets
configured to be in nonblocking mode so the lack of data does not hang 
things up.

In such cases, both the accept and recv functions set errno to 
EWOULDBLK.  See
the following code where I test the error after attempt to accept a socket.

    if (sd == INVALID_SOCKET) {
        rc = wrapperGetLastError();
        if (rc == EWOULDBLOCK) {
            /* There are no incomming sockets right now. */
            return;
        } else {
            if (wrapperData->isDebugging) {
                log_printf(WRAPPER_SOURCE_PROTOCOL, LEVEL_DEBUG,
                    "socket creation failed. (%d)", rc);
            }
            return;
        }
    }

To avoid the debug error messages you are seeing on startup, I am 
special casing
the EWOULDBLOCK code so that it silently fails.  Any other error will 
display a
debug error message.

Now the strange part.   On your system, accept is setting errno to a 
value of 11
when a socket is not available.   On Linux and every other system the 
Wrapper
works on to date, EWOULDBLOCK = 11.

Since the above code is failing on your system, EWOULDBLOCK is obviously
not = 11 with your compiler.    Could you place the following lines of 
code just
before the above code.

log_printf(WRAPPER_SOURCE_PROTOCOL, LEVEL_DEBUG,
    "errno 11 = %s", strerror(11));
log_printf(WRAPPER_SOURCE_PROTOCOL, LEVEL_DEBUG,
    "errno EWOULDBLOCK = %d = %s", EWOULDBLOCK, strerror(EWOULDBLOCK));

On linux, this prints out the following:
errno 11 = Resource temporarily unavailable
errno EWOULDBLOCK = 11 = Resource temporarily unavailable

Now on with the explanation...
In the case of accept, the above problem is simply causing an extra 
debug message
to be printed out.   But after a socket is connected, the Wrapper reads 
a packet
from the JVM immediately after it connects, but when it calls recv again 
to see if
there are any more packets, recv returns that there is no data and sets 
errno to 11.
Pretty much the same code fails to match this to EWOULDBLOCK and so
assumes that it is an unexpected socket error.   This leads to the 
socket being
closed and the JVM being restarted as you are seeing.

So the cause of all your problems is the value of the EWOULDBLOCK constant
on your system.

Could you try recompiling the c source and make sure that there are no 
warning
messages about this constant being undefined?  If the constant just has 
a different
value on your system, then recv and accept should still be using the 
constant and
returning that other value...

Cheers,
Leif

Leif Mortenson wrote:

> Venkatesh,
>    Sorry about the hassle getting your hands on a  64-bit build.   It 
> sounds like there are
> actually several such users out there.  Not having access to any 
> hardware however, I
> must rely on users willing to donate the time to maintain and build 
> such releases.  We
> have someone for the 32-bit version, but not the 64-bit version yet.  
> I have been
> hoping that there is a way to build both the 32-bit .so and 64-bit .sl 
> file on the same
> machine so that they can both be shipped with the HP-UX distribution.
>
>    See the answers to your questions below.
>
> Venkatesh Sellappa wrote:
>
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Please read the disclaimer at the bottom of this e-mail.
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>> Hi All,
>>
>> Congratulations on building an excellent product.
>> It fills a very important need in the Java market.
>>
>> For our production environment we are using the following:
>> 0.HP-UX 11i ( 64 bit )
>> 1.Java 1.4.2_03
>> 2.Wrapper version 3.1.0
>>
>> In the absence of a 64-bit binary library and hitting the problems 
>> discussed earlier in the mailing list,
>> with the 32-bit library.
>> Re: 
>> http://sourceforge.net/mailarchive/forum.php?thread_id=3751203&forum_id=11948 
>>
>>
>> I used the cc,make and ld native to HP-UX to build the libwrapper.sl 
>> library from source.(GNU utilities not being allowed).
>> The source files for building the library were 
>> wrapperjni_unix.c,wrapperinfo.c,wrapperjni.c.
>>
>> On changing the properties
>> wrapper.console.loglevel=DEBUG
>> wrapper.logfile.loglevel=DEBUG
>> from INFO to DEBUG
>>
>> I hit the following,
>> DEBUG OUTPUT
>> ------------
>> STATUS | wrapper  | 2004/06/29 13:20:34 | --> Wrapper Started as Console
>> DEBUG  | wrapperp | 2004/06/29 13:20:34 | server listening on port 
>> 32000.
>> ..
>> DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket creation failed. (11)
>> INFO   | jvm 1    | 2004/06/29 13:20:35 | Initializing...
>> DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket creation failed. (11)
>> ..
>> INFO   | jvm 1    | 2004/06/29 13:20:35 | Loaded native library: 
>> libwrapper.so
>> INFO   | jvm 1    | 2004/06/29 13:20:35 | Calling native 
>> initialization method.
>> INFO   | jvm 1    | 2004/06/29 13:20:35 | Inside native 
>> WrapperManager initialization method
>> ..
>> INFO   | jvm 1    | 2004/06/29 13:20:35 | 
>> WrapperManager.start(org.tanukisoftware.wrapper.test.Main@a981ca, 
>> args[]) called by thread: main
>> ..
>> INFO   | jvm 1    | 2004/06/29 13:20:35 | Open socket to wrapper...
>> INFO   | jvm 1    | 2004/06/29 13:20:35 | Opened Socket
>> INFO   | jvm 1    | 2004/06/29 13:20:35 | Send a packet KEY : 
>> HjjwQG4LdL3g_kNV
>> INFO   | jvm 1    | 2004/06/29 13:20:35 | 
>> handleSocket(Socket[addr=/127.0.0.1,port=32000,localport=57670])
>> DEBUG  | wrapperp | 2004/06/29 13:20:35 | accepted a socket from 
>> 127.0.0.1 on port 57670
>> ..
>> DEBUG  | wrapper  | 2004/06/29 13:20:35 | Start Application.
>> DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket creation failed. (11)
>> DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket not open, so packet 
>> not sent START : start
>> ERROR  | wrapper  | 2004/06/29 13:20:35 | Unable to send the start 
>> command to the JVM.
>>  
>>
> Strange.  The JVM is opening its socket to the JVM.  The Wrapper 
> appears to be
> correctly accepting the new socket, and trading keys correctly?(this 
> part is clipped?).
> But then when the  wrapper attempts to tell the Java side app to 
> start, it finds that the
> socket is no longer open.    I am wondering what happened in the 
> region that is cut
> out.
>
>> ERROR  | wrapper  | 2004/06/29 13:20:35 | Sending the JVM process a 
>> SIGTERM
>> ..
>> ERROR  | wrapper  | 2004/06/29 13:20:37 | Critical error: wait for 
>> JVM process failed (No child processes)
>>
>> END DEBUG OUTPUT
>> ----------------
>> Note 1:It still says libwrapper.so loaded, even though there is no 
>> libwrapper.so in the path, its libwrapper.sl
>>  
>>
> The actual location and loading of the library is being handled by the 
> JVM.   All I am
> able to do is to tell whether or not it was loaded.  Currently I 
> always display a message
> that libwrapper.so was loaded, with the exceptions of Wrapper.dll for 
> Windows and
> libwrapper.jnilib for OSX.   Until HP-UX, this has been correct for 
> all other platforms.
>
> If you know of any System property values which I can use to 
> distinguish between
> 32 and 64 bit versions then I can add a special case to correct this 
> message.
> On Solaris, the same so file seems to be working for both 32 and 64 
> bit versions of
> the OS.
>
>> Note 2:On changing the log level back to INFO from DEBUG it works fine
>>  
>>
> This could be one of two things.  A timing issue.  The startup would 
> be slightly faster
> without the debug output.   Or a corruption/synchronization problem 
> caused by the
> debug output itself.
>
> You have debug output enabled both the console and file.  What happens 
> if you only
> do one or the other?
>
>> Note 3:Using method 3 i integrated my application with the wrapper 
>> and hit the exact same problem, if i keep the wrapper loglevel at 
>> INFO and my application loglevel at DEBUG( using log4j )it works fine.
>> Note 4:The debug output has been truncated to make it a bit more 
>> readable, i can send the full log if required.
>>  
>>
> Could you send the full log file to me directly?   Keep all other 
> messages on
> list please.  Also send along your wrapper.conf file.   tar.gz them 
> both up
> before sending them off to make sure that the text attachments don't get
> reformated or anything.
>
> Recreate the log using the following:
>
> wrapper.console.loglevel=DEBUG
> wrapper.logfile.loglevel=DEBUG
> wrapper.state_output=TRUE
>
> The state output causes the main event loop to dump a message for each 
> cycle.  The
> log output goes way up, but it may help pit down the exact timing of 
> what is
> happening.
>
>> What other diagnostics can i run to narrow down the problem ?
>>  
>>
> Let me take a look at the log and I may have some more questions.
>
> Cheers,
> Leif

RE: [Wrapper-user] HP-UX 11i 64 bit:log level DEBUG crashes application

[Venkatesh S. <Ven...@lc...>]

++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Please read the disclaimer at the bottom of this e-mail.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

As an addendum,

linking the files with the +b option as explained here
http://www.hp.com/products1/unix/java/faq/index.html#troubleshoot11
does not solve the problem.

cheers,

-----Original Message-----
From: wra...@li...
[mailto:wra...@li...]On Behalf Of Venkatesh
Sellappa
Sent: 30 June 2004 09:39
To: wra...@li...
Subject: RE: [Wrapper-user] HP-UX 11i 64 bit:log level DEBUG crashes
application


++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Please read the disclaimer at the bottom of this e-mail.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Re:
The .so extension for a 64-bit library, i believe this is incorrect.
On building the library with a .so extension,it gives the same=20
"WARNING:Unable to load the Wrapper's native library 'libwrapper.so'.=20
......"

this error occurs if you attempt to run the 32-bit library on a 64-bit mach=
ine.
I am compiling,linking the library from the command line.( not comfortable =
with HP-make ).

I am going to try and have a look at the options described in the link.
http://www.hp.com/products1/unix/java/faq/index.html#troubleshoot11
Will post the results back to the mailing list.

Cheers,

-----Original Message-----
From: wra...@li...
[mailto:wra...@li...]On Behalf Of Andreas
Wendt
Sent: 30 June 2004 08:07
To: wra...@li...
Subject: Re: [Wrapper-user] HP-UX 11i 64 bit:log level DEBUG crashes
application


Venkatesh,

as far as I found out so far, 32-bit HP-UX uses the .sl extension, whereas =
64-bit uses the .so extension.
I also have only a 32-bit HP-UX at my hands, so I can't tell for sure what =
went wrong.
But I found the following on HP's site (that seems to describe your problem=
):

http://www.hp.com/products1/unix/java/faq/index.html#troubleshoot11

If you don't get further, it would be good to post the Makefile.

Cheers,
Andreas

>=20
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Please read the disclaimer at the bottom of this e-mail.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>=20
> Hi All,
>=20
> Congratulations on building an excellent product.
> It fills a very important need in the Java market.
>=20
> For our production environment we are using the following:
> 0.HP-UX 11i ( 64 bit )
> 1.Java 1.4.2_03
> 2.Wrapper version 3.1.0
>=20
> In the absence of a 64-bit binary library and hitting the problems discus=
sed earlier in the mailing list,
> with the 32-bit library.
> Re: http://sourceforge.net/mailarchive/forum.php?thread_id=3D3751203&foru=
m_id=3D11948
>=20
> I used the cc,make and ld native to HP-UX to build the libwrapper.sl libr=
ary from source.(GNU utilities not being allowed).
> The source files for building the library were wrapperjni_unix.c,wrapperi=
nfo.c,wrapperjni.c.
>=20
> On changing the properties
> wrapper.console.loglevel=3DDEBUG
> wrapper.logfile.loglevel=3DDEBUG
> from INFO to DEBUG
>=20
> I hit the following,
> DEBUG OUTPUT
> ------------
> STATUS | wrapper  | 2004/06/29 13:20:34 | --> Wrapper Started as Console
> DEBUG  | wrapperp | 2004/06/29 13:20:34 | server listening on port 32000.
> ..
> DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket creation failed. (11)
> INFO   | jvm 1    | 2004/06/29 13:20:35 | Initializing...
> DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket creation failed. (11)
> ..
> INFO   | jvm 1    | 2004/06/29 13:20:35 | Loaded native library: libwrapp=
er.so
> INFO   | jvm 1    | 2004/06/29 13:20:35 | Calling native initialization m=
ethod.
> INFO   | jvm 1    | 2004/06/29 13:20:35 | Inside native WrapperManager in=
itialization method
> ..
> INFO   | jvm 1    | 2004/06/29 13:20:35 | WrapperManager.start(org.tanuki=
software.wrapper.test.Main@a981ca, args[]) called by thread: main
> ..
> INFO   | jvm 1    | 2004/06/29 13:20:35 | Open socket to wrapper...
> INFO   | jvm 1    | 2004/06/29 13:20:35 | Opened Socket
> INFO   | jvm 1    | 2004/06/29 13:20:35 | Send a packet KEY : HjjwQG4LdL3=
g_kNV
> INFO   | jvm 1    | 2004/06/29 13:20:35 | handleSocket(Socket[addr=3D/127=
.0.0.1,port=3D32000,localport=3D57670])
> DEBUG  | wrapperp | 2004/06/29 13:20:35 | accepted a socket from 127.0.0.=
1 on port 57670
> ..
> DEBUG  | wrapper  | 2004/06/29 13:20:35 | Start Application.
> DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket creation failed. (11)
> DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket not open, so packet not =
sent START : start
> ERROR  | wrapper  | 2004/06/29 13:20:35 | Unable to send the start comman=
d to the JVM.
> ERROR  | wrapper  | 2004/06/29 13:20:35 | Sending the JVM process a SIGTE=
RM
> ..
> ERROR  | wrapper  | 2004/06/29 13:20:37 | Critical error: wait for JVM pr=
ocess failed (No child processes)
>=20
> END DEBUG OUTPUT
> ----------------
> Note 1:It still says libwrapper.so loaded, even though there is no libwra=
pper.so in the path, its libwrapper.sl
> Note 2:On changing the log level back to INFO from DEBUG it works fine
> Note 3:Using method 3 i integrated my application with the wrapper and hi=
t the exact same problem, if i keep the wrapper loglevel at INFO and my app=
lication loglevel at DEBUG( using log4j )it works fine.
> Note 4:The debug output has been truncated to make it a bit more readable=
, i can send the full log if required.
>=20
> What other diagnostics can i run to narrow down the problem ?
>=20
> Rgds,
> Venkatesh S.


**********************************************************************
This email is intended for the named recipient(s) only. Its contents
are  confidential and may only be retained by the named recipient(s)
and may only be copied or  disclosed  with the consent of=20
LCH.Clearnet Limited.   If you are not an intended recipient please
delete this e-mail and notify pos...@lc....

The contents  of this  email are  subject to  contract in all cases,=20
and LCH.Clearnet Limited makes no contractual commitment save where
confirmed by hard copy.  LCH.Clearnet Limited accepts no liability,=20
including liability for negligence, in respect of any statement in=20
this email.

LCH.Clearnet Limited, Registered Office: Aldgate House,=20
33 Aldgate High Street, London EC3N 1EA.    Recognised as a Clearing=20
House under the Financial Services & Markets Act 2000. Reg in England No.25=
932=20
Telephone: +44 20 7426 7000              Internet: http://www.lchclearnet.c=
om
**********************************************************************

RE: [Wrapper-user] HP-UX 11i 64 bit:log level DEBUG crashes application

[Venkatesh S. <Ven...@lc...>]

++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Please read the disclaimer at the bottom of this e-mail.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Hi Leif,

I am willing to create/maintain the 64-bit releases as long as i=20
have access to the hardware.
Though i am more conversant with the Linux versions of the tools required t=
hen the=20
HP-UX ones,so do bear with me on that.

Answers to the questions:
>You have debug output enabled both the console and file.  What happens=20
>if you only
>do one or the other?
The effect is the same, the wrapper crashes with the exact same errors.

I have mailed you the log files.
Hope that helps.

Cheers,

-----Original Message-----
From: wra...@li...
[mailto:wra...@li...]On Behalf Of Leif
Mortenson
Sent: 30 June 2004 05:00
To: wra...@li...
Subject: Re: [Wrapper-user] HP-UX 11i 64 bit:log level DEBUG crashes
application


Venkatesh,
    Sorry about the hassle getting your hands on a  64-bit build.   It=20
sounds like there are
actually several such users out there.  Not having access to any=20
hardware however, I
must rely on users willing to donate the time to maintain and build such=20
releases.  We
have someone for the 32-bit version, but not the 64-bit version yet.  I=20
have been
hoping that there is a way to build both the 32-bit .so and 64-bit .sl=20
file on the same
machine so that they can both be shipped with the HP-UX distribution.

    See the answers to your questions below.

Venkatesh Sellappa wrote:

>Hi All,
>
>Congratulations on building an excellent product.
>It fills a very important need in the Java market.
>
>For our production environment we are using the following:
>0.HP-UX 11i ( 64 bit )
>1.Java 1.4.2_03
>2.Wrapper version 3.1.0
>
>In the absence of a 64-bit binary library and hitting the problems discuss=
ed earlier in the mailing list,
>with the 32-bit library.
>Re: http://sourceforge.net/mailarchive/forum.php?thread_id=3D3751203&forum=
_id=3D11948
>
>I used the cc,make and ld native to HP-UX to build the libwrapper.sl libra=
ry from source.(GNU utilities not being allowed).
>The source files for building the library were wrapperjni_unix.c,wrapperin=
fo.c,wrapperjni.c.
>
>On changing the properties
>wrapper.console.loglevel=3DDEBUG
>wrapper.logfile.loglevel=3DDEBUG
>from INFO to DEBUG
>
>I hit the following,
>DEBUG OUTPUT
>------------
>STATUS | wrapper  | 2004/06/29 13:20:34 | --> Wrapper Started as Console
>DEBUG  | wrapperp | 2004/06/29 13:20:34 | server listening on port 32000.
>..
>DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket creation failed. (11)
>INFO   | jvm 1    | 2004/06/29 13:20:35 | Initializing...
>DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket creation failed. (11)
>..
>INFO   | jvm 1    | 2004/06/29 13:20:35 | Loaded native library: libwrappe=
r.so
>INFO   | jvm 1    | 2004/06/29 13:20:35 | Calling native initialization me=
thod.
>INFO   | jvm 1    | 2004/06/29 13:20:35 | Inside native WrapperManager ini=
tialization method
>..
>INFO   | jvm 1    | 2004/06/29 13:20:35 | WrapperManager.start(org.tanukis=
oftware.wrapper.test.Main@a981ca, args[]) called by thread: main
>..
>INFO   | jvm 1    | 2004/06/29 13:20:35 | Open socket to wrapper...
>INFO   | jvm 1    | 2004/06/29 13:20:35 | Opened Socket
>INFO   | jvm 1    | 2004/06/29 13:20:35 | Send a packet KEY : HjjwQG4LdL3g=
_kNV
>INFO   | jvm 1    | 2004/06/29 13:20:35 | handleSocket(Socket[addr=3D/127.=
0.0.1,port=3D32000,localport=3D57670])
>DEBUG  | wrapperp | 2004/06/29 13:20:35 | accepted a socket from 127.0.0.1=
 on port 57670
>..
>DEBUG  | wrapper  | 2004/06/29 13:20:35 | Start Application.
>DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket creation failed. (11)
>DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket not open, so packet not s=
ent START : start
>ERROR  | wrapper  | 2004/06/29 13:20:35 | Unable to send the start command=
 to the JVM.
> =20
>
Strange.  The JVM is opening its socket to the JVM.  The Wrapper appears=20
to be
correctly accepting the new socket, and trading keys correctly?(this=20
part is clipped?).
But then when the  wrapper attempts to tell the Java side app to start,=20
it finds that the
socket is no longer open.    I am wondering what happened in the region=20
that is cut
out.

>ERROR  | wrapper  | 2004/06/29 13:20:35 | Sending the JVM process a SIGTERM
>..
>ERROR  | wrapper  | 2004/06/29 13:20:37 | Critical error: wait for JVM pro=
cess failed (No child processes)
>
>END DEBUG OUTPUT
>----------------
>Note 1:It still says libwrapper.so loaded, even though there is no libwrap=
per.so in the path, its libwrapper.sl
> =20
>
The actual location and loading of the library is being handled by the=20
JVM.   All I am
able to do is to tell whether or not it was loaded.  Currently I always=20
display a message
that libwrapper.so was loaded, with the exceptions of Wrapper.dll for=20
Windows and
libwrapper.jnilib for OSX.   Until HP-UX, this has been correct for all=20
other platforms.

If you know of any System property values which I can use to distinguish=20
between
32 and 64 bit versions then I can add a special case to correct this=20
message.
On Solaris, the same so file seems to be working for both 32 and 64 bit=20
versions of
the OS.

>Note 2:On changing the log level back to INFO from DEBUG it works fine
> =20
>
This could be one of two things.  A timing issue.  The startup would be=20
slightly faster
without the debug output.   Or a corruption/synchronization problem=20
caused by the
debug output itself.

You have debug output enabled both the console and file.  What happens=20
if you only
do one or the other?

>Note 3:Using method 3 i integrated my application with the wrapper and hit=
 the exact same problem, if i keep the wrapper loglevel at INFO and my appl=
ication loglevel at DEBUG( using log4j )it works fine.
>Note 4:The debug output has been truncated to make it a bit more readable,=
 i can send the full log if required.
> =20
>
Could you send the full log file to me directly?   Keep all other=20
messages on
list please.  Also send along your wrapper.conf file.   tar.gz them both up
before sending them off to make sure that the text attachments don't get
reformated or anything.

Recreate the log using the following:

wrapper.console.loglevel=3DDEBUG
wrapper.logfile.loglevel=3DDEBUG
wrapper.state_output=3DTRUE

The state output causes the main event loop to dump a message for each=20
cycle.  The
log output goes way up, but it may help pit down the exact timing of what is
happening.

>What other diagnostics can i run to narrow down the problem ?
> =20
>
Let me take a look at the log and I may have some more questions.

Cheers,
Leif


**********************************************************************
This email is intended for the named recipient(s) only. Its contents
are  confidential and may only be retained by the named recipient(s)
and may only be copied or  disclosed  with the consent of=20
LCH.Clearnet Limited.   If you are not an intended recipient please
delete this e-mail and notify pos...@lc....

The contents  of this  email are  subject to  contract in all cases,=20
and LCH.Clearnet Limited makes no contractual commitment save where
confirmed by hard copy.  LCH.Clearnet Limited accepts no liability,=20
including liability for negligence, in respect of any statement in=20
this email.

LCH.Clearnet Limited, Registered Office: Aldgate House,=20
33 Aldgate High Street, London EC3N 1EA.    Recognised as a Clearing=20
House under the Financial Services & Markets Act 2000. Reg in England No.25=
932=20
Telephone: +44 20 7426 7000              Internet: http://www.lchclearnet.c=
om
**********************************************************************

RE: [Wrapper-user] HP-UX 11i 64 bit:log level DEBUG crashes application

[Venkatesh S. <Ven...@lc...>]

++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Please read the disclaimer at the bottom of this e-mail.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Re:
The .so extension for a 64-bit library, i believe this is incorrect.
On building the library with a .so extension,it gives the same=20
"WARNING:Unable to load the Wrapper's native library 'libwrapper.so'.=20
......"

this error occurs if you attempt to run the 32-bit library on a 64-bit mach=
ine.
I am compiling,linking the library from the command line.( not comfortable =
with HP-make ).

I am going to try and have a look at the options described in the link.
http://www.hp.com/products1/unix/java/faq/index.html#troubleshoot11
Will post the results back to the mailing list.

Cheers,

-----Original Message-----
From: wra...@li...
[mailto:wra...@li...]On Behalf Of Andreas
Wendt
Sent: 30 June 2004 08:07
To: wra...@li...
Subject: Re: [Wrapper-user] HP-UX 11i 64 bit:log level DEBUG crashes
application


Venkatesh,

as far as I found out so far, 32-bit HP-UX uses the .sl extension, whereas =
64-bit uses the .so extension.
I also have only a 32-bit HP-UX at my hands, so I can't tell for sure what =
went wrong.
But I found the following on HP's site (that seems to describe your problem=
):

http://www.hp.com/products1/unix/java/faq/index.html#troubleshoot11

If you don't get further, it would be good to post the Makefile.

Cheers,
Andreas

>=20
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Please read the disclaimer at the bottom of this e-mail.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>=20
> Hi All,
>=20
> Congratulations on building an excellent product.
> It fills a very important need in the Java market.
>=20
> For our production environment we are using the following:
> 0.HP-UX 11i ( 64 bit )
> 1.Java 1.4.2_03
> 2.Wrapper version 3.1.0
>=20
> In the absence of a 64-bit binary library and hitting the problems discus=
sed earlier in the mailing list,
> with the 32-bit library.
> Re: http://sourceforge.net/mailarchive/forum.php?thread_id=3D3751203&foru=
m_id=3D11948
>=20
> I used the cc,make and ld native to HP-UX to build the libwrapper.sl libr=
ary from source.(GNU utilities not being allowed).
> The source files for building the library were wrapperjni_unix.c,wrapperi=
nfo.c,wrapperjni.c.
>=20
> On changing the properties
> wrapper.console.loglevel=3DDEBUG
> wrapper.logfile.loglevel=3DDEBUG
> from INFO to DEBUG
>=20
> I hit the following,
> DEBUG OUTPUT
> ------------
> STATUS | wrapper  | 2004/06/29 13:20:34 | --> Wrapper Started as Console
> DEBUG  | wrapperp | 2004/06/29 13:20:34 | server listening on port 32000.
> ..
> DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket creation failed. (11)
> INFO   | jvm 1    | 2004/06/29 13:20:35 | Initializing...
> DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket creation failed. (11)
> ..
> INFO   | jvm 1    | 2004/06/29 13:20:35 | Loaded native library: libwrapp=
er.so
> INFO   | jvm 1    | 2004/06/29 13:20:35 | Calling native initialization m=
ethod.
> INFO   | jvm 1    | 2004/06/29 13:20:35 | Inside native WrapperManager in=
itialization method
> ..
> INFO   | jvm 1    | 2004/06/29 13:20:35 | WrapperManager.start(org.tanuki=
software.wrapper.test.Main@a981ca, args[]) called by thread: main
> ..
> INFO   | jvm 1    | 2004/06/29 13:20:35 | Open socket to wrapper...
> INFO   | jvm 1    | 2004/06/29 13:20:35 | Opened Socket
> INFO   | jvm 1    | 2004/06/29 13:20:35 | Send a packet KEY : HjjwQG4LdL3=
g_kNV
> INFO   | jvm 1    | 2004/06/29 13:20:35 | handleSocket(Socket[addr=3D/127=
.0.0.1,port=3D32000,localport=3D57670])
> DEBUG  | wrapperp | 2004/06/29 13:20:35 | accepted a socket from 127.0.0.=
1 on port 57670
> ..
> DEBUG  | wrapper  | 2004/06/29 13:20:35 | Start Application.
> DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket creation failed. (11)
> DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket not open, so packet not =
sent START : start
> ERROR  | wrapper  | 2004/06/29 13:20:35 | Unable to send the start comman=
d to the JVM.
> ERROR  | wrapper  | 2004/06/29 13:20:35 | Sending the JVM process a SIGTE=
RM
> ..
> ERROR  | wrapper  | 2004/06/29 13:20:37 | Critical error: wait for JVM pr=
ocess failed (No child processes)
>=20
> END DEBUG OUTPUT
> ----------------
> Note 1:It still says libwrapper.so loaded, even though there is no libwra=
pper.so in the path, its libwrapper.sl
> Note 2:On changing the log level back to INFO from DEBUG it works fine
> Note 3:Using method 3 i integrated my application with the wrapper and hi=
t the exact same problem, if i keep the wrapper loglevel at INFO and my app=
lication loglevel at DEBUG( using log4j )it works fine.
> Note 4:The debug output has been truncated to make it a bit more readable=
, i can send the full log if required.
>=20
> What other diagnostics can i run to narrow down the problem ?
>=20
> Rgds,
> Venkatesh S.
>=20
>=20
>=20
>=20
>=20
> **********************************************************************
> This email is intended for the named recipient(s) only. Its contents
> are  confidential and may only be retained by the named recipient(s)
> and may only be copied or  disclosed  with the consent of=20
> LCH.Clearnet Limited.   If you are not an intended recipient please
> delete this e-mail and notify pos...@lc....
>=20
> The contents  of this  email are  subject to  contract in all cases,=20
> and LCH.Clearnet Limited makes no contractual commitment save where
> confirmed by hard copy.  LCH.Clearnet Limited accepts no liability,=20
> including liability for negligence, in respect of any statement in=20
> this email.
>=20
> LCH.Clearnet Limited, Registered Office: Aldgate House,=20
> 33 Aldgate High Street, London EC3N 1EA.    Recognised as a Clearing=20
> House under the Financial Services & Markets Act 2000. Reg in England No.=
25932=20
> Telephone: +44 20 7426 7000              Internet: http://www.lchclearnet=
.com
> **********************************************************************
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20
> digital self defense, top technical experts, no vendor pitches,=20
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user





-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20
digital self defense, top technical experts, no vendor pitches,=20
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user


**********************************************************************
This email is intended for the named recipient(s) only. Its contents
are  confidential and may only be retained by the named recipient(s)
and may only be copied or  disclosed  with the consent of=20
LCH.Clearnet Limited.   If you are not an intended recipient please
delete this e-mail and notify pos...@lc....

The contents  of this  email are  subject to  contract in all cases,=20
and LCH.Clearnet Limited makes no contractual commitment save where
confirmed by hard copy.  LCH.Clearnet Limited accepts no liability,=20
including liability for negligence, in respect of any statement in=20
this email.

LCH.Clearnet Limited, Registered Office: Aldgate House,=20
33 Aldgate High Street, London EC3N 1EA.    Recognised as a Clearing=20
House under the Financial Services & Markets Act 2000. Reg in England No.25=
932=20
Telephone: +44 20 7426 7000              Internet: http://www.lchclearnet.c=
om
**********************************************************************

Re: [Wrapper-user] HP-UX 11i 64 bit:log level DEBUG crashes application

[Andreas W. <and...@em...>]

Venkatesh,

as far as I found out so far, 32-bit HP-UX uses the .sl extension, whereas 64-bit uses the .so extension.
I also have only a 32-bit HP-UX at my hands, so I can't tell for sure what went wrong.
But I found the following on HP's site (that seems to describe your problem):

http://www.hp.com/products1/unix/java/faq/index.html#troubleshoot11

If you don't get further, it would be good to post the Makefile.

Cheers,
Andreas

> 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Please read the disclaimer at the bottom of this e-mail.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> Hi All,
> 
> Congratulations on building an excellent product.
> It fills a very important need in the Java market.
> 
> For our production environment we are using the following:
> 0.HP-UX 11i ( 64 bit )
> 1.Java 1.4.2_03
> 2.Wrapper version 3.1.0
> 
> In the absence of a 64-bit binary library and hitting the problems discussed earlier in the mailing list,
> with the 32-bit library.
> Re: http://sourceforge.net/mailarchive/forum.php?thread_id=3751203&forum_id=11948
> 
> I used the cc,make and ld native to HP-UX to build the libwrapper.sl library from source.(GNU utilities not being allowed).
> The source files for building the library were wrapperjni_unix.c,wrapperinfo.c,wrapperjni.c.
> 
> On changing the properties
> wrapper.console.loglevel=DEBUG
> wrapper.logfile.loglevel=DEBUG
> from INFO to DEBUG
> 
> I hit the following,
> DEBUG OUTPUT
> ------------
> STATUS | wrapper  | 2004/06/29 13:20:34 | --> Wrapper Started as Console
> DEBUG  | wrapperp | 2004/06/29 13:20:34 | server listening on port 32000.
> ..
> DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket creation failed. (11)
> INFO   | jvm 1    | 2004/06/29 13:20:35 | Initializing...
> DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket creation failed. (11)
> ..
> INFO   | jvm 1    | 2004/06/29 13:20:35 | Loaded native library: libwrapper.so
> INFO   | jvm 1    | 2004/06/29 13:20:35 | Calling native initialization method.
> INFO   | jvm 1    | 2004/06/29 13:20:35 | Inside native WrapperManager initialization method
> ..
> INFO   | jvm 1    | 2004/06/29 13:20:35 | WrapperManager.start(org.tanukisoftware.wrapper.test.Main@a981ca, args[]) called by thread: main
> ..
> INFO   | jvm 1    | 2004/06/29 13:20:35 | Open socket to wrapper...
> INFO   | jvm 1    | 2004/06/29 13:20:35 | Opened Socket
> INFO   | jvm 1    | 2004/06/29 13:20:35 | Send a packet KEY : HjjwQG4LdL3g_kNV
> INFO   | jvm 1    | 2004/06/29 13:20:35 | handleSocket(Socket[addr=/127.0.0.1,port=32000,localport=57670])
> DEBUG  | wrapperp | 2004/06/29 13:20:35 | accepted a socket from 127.0.0.1 on port 57670
> ..
> DEBUG  | wrapper  | 2004/06/29 13:20:35 | Start Application.
> DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket creation failed. (11)
> DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket not open, so packet not sent START : start
> ERROR  | wrapper  | 2004/06/29 13:20:35 | Unable to send the start command to the JVM.
> ERROR  | wrapper  | 2004/06/29 13:20:35 | Sending the JVM process a SIGTERM
> ..
> ERROR  | wrapper  | 2004/06/29 13:20:37 | Critical error: wait for JVM process failed (No child processes)
> 
> END DEBUG OUTPUT
> ----------------
> Note 1:It still says libwrapper.so loaded, even though there is no libwrapper.so in the path, its libwrapper.sl
> Note 2:On changing the log level back to INFO from DEBUG it works fine
> Note 3:Using method 3 i integrated my application with the wrapper and hit the exact same problem, if i keep the wrapper loglevel at INFO and my application loglevel at DEBUG( using log4j )it works fine.
> Note 4:The debug output has been truncated to make it a bit more readable, i can send the full log if required.
> 
> What other diagnostics can i run to narrow down the problem ?
> 
> Rgds,
> Venkatesh S.
> 
> 
> 
> 
> 
> **********************************************************************
> This email is intended for the named recipient(s) only. Its contents
> are  confidential and may only be retained by the named recipient(s)
> and may only be copied or  disclosed  with the consent of 
> LCH.Clearnet Limited.   If you are not an intended recipient please
> delete this e-mail and notify pos...@lc....
> 
> The contents  of this  email are  subject to  contract in all cases, 
> and LCH.Clearnet Limited makes no contractual commitment save where
> confirmed by hard copy.  LCH.Clearnet Limited accepts no liability, 
> including liability for negligence, in respect of any statement in 
> this email.
> 
> LCH.Clearnet Limited, Registered Office: Aldgate House, 
> 33 Aldgate High Street, London EC3N 1EA.    Recognised as a Clearing 
> House under the Financial Services & Markets Act 2000. Reg in England No.25932 
> Telephone: +44 20 7426 7000              Internet: http://www.lchclearnet.com
> **********************************************************************
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] HP-UX 11i 64 bit:log level DEBUG crashes application

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

Venkatesh,
    Sorry about the hassle getting your hands on a  64-bit build.   It 
sounds like there are
actually several such users out there.  Not having access to any 
hardware however, I
must rely on users willing to donate the time to maintain and build such 
releases.  We
have someone for the 32-bit version, but not the 64-bit version yet.  I 
have been
hoping that there is a way to build both the 32-bit .so and 64-bit .sl 
file on the same
machine so that they can both be shipped with the HP-UX distribution.

    See the answers to your questions below.

Venkatesh Sellappa wrote:

>++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>Please read the disclaimer at the bottom of this e-mail.
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>Hi All,
>
>Congratulations on building an excellent product.
>It fills a very important need in the Java market.
>
>For our production environment we are using the following:
>0.HP-UX 11i ( 64 bit )
>1.Java 1.4.2_03
>2.Wrapper version 3.1.0
>
>In the absence of a 64-bit binary library and hitting the problems discussed earlier in the mailing list,
>with the 32-bit library.
>Re: http://sourceforge.net/mailarchive/forum.php?thread_id=3751203&forum_id=11948
>
>I used the cc,make and ld native to HP-UX to build the libwrapper.sl library from source.(GNU utilities not being allowed).
>The source files for building the library were wrapperjni_unix.c,wrapperinfo.c,wrapperjni.c.
>
>On changing the properties
>wrapper.console.loglevel=DEBUG
>wrapper.logfile.loglevel=DEBUG
>from INFO to DEBUG
>
>I hit the following,
>DEBUG OUTPUT
>------------
>STATUS | wrapper  | 2004/06/29 13:20:34 | --> Wrapper Started as Console
>DEBUG  | wrapperp | 2004/06/29 13:20:34 | server listening on port 32000.
>..
>DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket creation failed. (11)
>INFO   | jvm 1    | 2004/06/29 13:20:35 | Initializing...
>DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket creation failed. (11)
>..
>INFO   | jvm 1    | 2004/06/29 13:20:35 | Loaded native library: libwrapper.so
>INFO   | jvm 1    | 2004/06/29 13:20:35 | Calling native initialization method.
>INFO   | jvm 1    | 2004/06/29 13:20:35 | Inside native WrapperManager initialization method
>..
>INFO   | jvm 1    | 2004/06/29 13:20:35 | WrapperManager.start(org.tanukisoftware.wrapper.test.Main@a981ca, args[]) called by thread: main
>..
>INFO   | jvm 1    | 2004/06/29 13:20:35 | Open socket to wrapper...
>INFO   | jvm 1    | 2004/06/29 13:20:35 | Opened Socket
>INFO   | jvm 1    | 2004/06/29 13:20:35 | Send a packet KEY : HjjwQG4LdL3g_kNV
>INFO   | jvm 1    | 2004/06/29 13:20:35 | handleSocket(Socket[addr=/127.0.0.1,port=32000,localport=57670])
>DEBUG  | wrapperp | 2004/06/29 13:20:35 | accepted a socket from 127.0.0.1 on port 57670
>..
>DEBUG  | wrapper  | 2004/06/29 13:20:35 | Start Application.
>DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket creation failed. (11)
>DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket not open, so packet not sent START : start
>ERROR  | wrapper  | 2004/06/29 13:20:35 | Unable to send the start command to the JVM.
>  
>
Strange.  The JVM is opening its socket to the JVM.  The Wrapper appears 
to be
correctly accepting the new socket, and trading keys correctly?(this 
part is clipped?).
But then when the  wrapper attempts to tell the Java side app to start, 
it finds that the
socket is no longer open.    I am wondering what happened in the region 
that is cut
out.

>ERROR  | wrapper  | 2004/06/29 13:20:35 | Sending the JVM process a SIGTERM
>..
>ERROR  | wrapper  | 2004/06/29 13:20:37 | Critical error: wait for JVM process failed (No child processes)
>
>END DEBUG OUTPUT
>----------------
>Note 1:It still says libwrapper.so loaded, even though there is no libwrapper.so in the path, its libwrapper.sl
>  
>
The actual location and loading of the library is being handled by the 
JVM.   All I am
able to do is to tell whether or not it was loaded.  Currently I always 
display a message
that libwrapper.so was loaded, with the exceptions of Wrapper.dll for 
Windows and
libwrapper.jnilib for OSX.   Until HP-UX, this has been correct for all 
other platforms.

If you know of any System property values which I can use to distinguish 
between
32 and 64 bit versions then I can add a special case to correct this 
message.
On Solaris, the same so file seems to be working for both 32 and 64 bit 
versions of
the OS.

>Note 2:On changing the log level back to INFO from DEBUG it works fine
>  
>
This could be one of two things.  A timing issue.  The startup would be 
slightly faster
without the debug output.   Or a corruption/synchronization problem 
caused by the
debug output itself.

You have debug output enabled both the console and file.  What happens 
if you only
do one or the other?

>Note 3:Using method 3 i integrated my application with the wrapper and hit the exact same problem, if i keep the wrapper loglevel at INFO and my application loglevel at DEBUG( using log4j )it works fine.
>Note 4:The debug output has been truncated to make it a bit more readable, i can send the full log if required.
>  
>
Could you send the full log file to me directly?   Keep all other 
messages on
list please.  Also send along your wrapper.conf file.   tar.gz them both up
before sending them off to make sure that the text attachments don't get
reformated or anything.

Recreate the log using the following:

wrapper.console.loglevel=DEBUG
wrapper.logfile.loglevel=DEBUG
wrapper.state_output=TRUE

The state output causes the main event loop to dump a message for each 
cycle.  The
log output goes way up, but it may help pit down the exact timing of what is
happening.

>What other diagnostics can i run to narrow down the problem ?
>  
>
Let me take a look at the log and I may have some more questions.

Cheers,
Leif

[Wrapper-user] HP-UX 11i 64 bit:log level DEBUG crashes application

[Venkatesh S. <Ven...@lc...>]

++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Please read the disclaimer at the bottom of this e-mail.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Hi All,

Congratulations on building an excellent product.
It fills a very important need in the Java market.

For our production environment we are using the following:
0.HP-UX 11i ( 64 bit )
1.Java 1.4.2_03
2.Wrapper version 3.1.0

In the absence of a 64-bit binary library and hitting the problems discusse=
d earlier in the mailing list,
with the 32-bit library.
Re: http://sourceforge.net/mailarchive/forum.php?thread_id=3D3751203&forum_=
id=3D11948

I used the cc,make and ld native to HP-UX to build the libwrapper.sl librar=
y from source.(GNU utilities not being allowed).
The source files for building the library were wrapperjni_unix.c,wrapperinf=
o.c,wrapperjni.c.

On changing the properties
wrapper.console.loglevel=3DDEBUG
wrapper.logfile.loglevel=3DDEBUG
from INFO to DEBUG

I hit the following,
DEBUG OUTPUT
------------
STATUS | wrapper  | 2004/06/29 13:20:34 | --> Wrapper Started as Console
DEBUG  | wrapperp | 2004/06/29 13:20:34 | server listening on port 32000.
..
DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket creation failed. (11)
INFO   | jvm 1    | 2004/06/29 13:20:35 | Initializing...
DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket creation failed. (11)
..
INFO   | jvm 1    | 2004/06/29 13:20:35 | Loaded native library: libwrapper=
.so
INFO   | jvm 1    | 2004/06/29 13:20:35 | Calling native initialization met=
hod.
INFO   | jvm 1    | 2004/06/29 13:20:35 | Inside native WrapperManager init=
ialization method
..
INFO   | jvm 1    | 2004/06/29 13:20:35 | WrapperManager.start(org.tanukiso=
ftware.wrapper.test.Main@a981ca, args[]) called by thread: main
..
INFO   | jvm 1    | 2004/06/29 13:20:35 | Open socket to wrapper...
INFO   | jvm 1    | 2004/06/29 13:20:35 | Opened Socket
INFO   | jvm 1    | 2004/06/29 13:20:35 | Send a packet KEY : HjjwQG4LdL3g_=
kNV
INFO   | jvm 1    | 2004/06/29 13:20:35 | handleSocket(Socket[addr=3D/127.0=
.0.1,port=3D32000,localport=3D57670])
DEBUG  | wrapperp | 2004/06/29 13:20:35 | accepted a socket from 127.0.0.1 =
on port 57670
..
DEBUG  | wrapper  | 2004/06/29 13:20:35 | Start Application.
DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket creation failed. (11)
DEBUG  | wrapperp | 2004/06/29 13:20:35 | socket not open, so packet not se=
nt START : start
ERROR  | wrapper  | 2004/06/29 13:20:35 | Unable to send the start command =
to the JVM.
ERROR  | wrapper  | 2004/06/29 13:20:35 | Sending the JVM process a SIGTERM
..
ERROR  | wrapper  | 2004/06/29 13:20:37 | Critical error: wait for JVM proc=
ess failed (No child processes)

END DEBUG OUTPUT
----------------
Note 1:It still says libwrapper.so loaded, even though there is no libwrapp=
er.so in the path, its libwrapper.sl
Note 2:On changing the log level back to INFO from DEBUG it works fine
Note 3:Using method 3 i integrated my application with the wrapper and hit =
the exact same problem, if i keep the wrapper loglevel at INFO and my appli=
cation loglevel at DEBUG( using log4j )it works fine.
Note 4:The debug output has been truncated to make it a bit more readable, =
i can send the full log if required.

What other diagnostics can i run to narrow down the problem ?

Rgds,
Venkatesh S.





**********************************************************************
This email is intended for the named recipient(s) only. Its contents
are  confidential and may only be retained by the named recipient(s)
and may only be copied or  disclosed  with the consent of=20
LCH.Clearnet Limited.   If you are not an intended recipient please
delete this e-mail and notify pos...@lc....

The contents  of this  email are  subject to  contract in all cases,=20
and LCH.Clearnet Limited makes no contractual commitment save where
confirmed by hard copy.  LCH.Clearnet Limited accepts no liability,=20
including liability for negligence, in respect of any statement in=20
this email.

LCH.Clearnet Limited, Registered Office: Aldgate House,=20
33 Aldgate High Street, London EC3N 1EA.    Recognised as a Clearing=20
House under the Financial Services & Markets Act 2000. Reg in England No.25=
932=20
Telephone: +44 20 7426 7000              Internet: http://www.lchclearnet.c=
om
**********************************************************************

[Wrapper-user] Re: APP exists

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

Omar,
The problem is that you are trying to run an application that was
compiled for a new JVM on an old JVM. As this is happening when
you are running as a service, most likely this is a path problem.

As I said in my last message to you. Please set the following property:
wrapper.debug=true

This will show you the full command used to launch the JVM as well as
the path to the JVM being run. When running as a service, the Wrapper
by default runs as the SYSTEM user and its PATH settings may not be
the same.

Rather than using this:
wrapper.java.command=java

Try using:
wrapper.java.command=%JAVA_HOME%/bin/java

Or:
wrapper.java.command=C:/j2sdk1.4.2_04/bin/java

Cheers,
Leif



Omar F. Rodriguez wrote:

>I got this, is this some version problem with the JVM
>
>STATUS | wrapper | 2004/06/25 12:34:36 | --> Wrapper Started as Service
>STATUS | wrapper | 2004/06/25 12:34:36 | Launching a JVM...
>INFO | jvm 1 | 2004/06/25 12:34:38 |
>java.lang.UnsupportedClassVersionError: gti/cnr/gob/sv/OC4JService
>(Unsupported major.minor version 48.0)
>INFO | jvm 1 | 2004/06/25 12:34:38 | at
>java.lang.ClassLoader.defineClass0(Native Method)
>INFO | jvm 1 | 2004/06/25 12:34:38 | at
>java.lang.ClassLoader.defineClass(ClassLoader.java:486)
>INFO | jvm 1 | 2004/06/25 12:34:38 | at
>java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
>INFO | jvm 1 | 2004/06/25 12:34:38 | at
>java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
>INFO | jvm 1 | 2004/06/25 12:34:38 | at
>java.net.URLClassLoader.access$100(URLClassLoader.java:56)
>INFO | jvm 1 | 2004/06/25 12:34:38 | at
>java.net.URLClassLoader$1.run(URLClassLoader.java:195)
>INFO | jvm 1 | 2004/06/25 12:34:38 | at
>java.security.AccessController.doPrivileged(Native Method)
>INFO | jvm 1 | 2004/06/25 12:34:38 | at
>java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>INFO | jvm 1 | 2004/06/25 12:34:38 | at
>java.lang.ClassLoader.loadClass(ClassLoader.java:297)
>INFO | jvm 1 | 2004/06/25 12:34:38 | at
>sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)
>INFO | jvm 1 | 2004/06/25 12:34:38 | at
>java.lang.ClassLoader.loadClass(ClassLoader.java:253)
>INFO | jvm 1 | 2004/06/25 12:34:38 | at
>java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
>INFO | jvm 1 | 2004/06/25 12:34:38 | Exception in thread "main"
>ERROR | wrapper | 2004/06/25 12:34:38 | JVM exited while loading the
>application.
>STATUS | wrapper | 2004/06/25 12:34:42 | Launching a JVM...
>INFO | jvm 2 | 2004/06/25 12:34:42 |
>java.lang.UnsupportedClassVersionError: gti/cnr/gob/sv/OC4JService
>(Unsupported major.minor version 48.0)
>INFO | jvm 2 | 2004/06/25 12:34:42 | at
>java.lang.ClassLoader.defineClass0(Native Method)
>INFO | jvm 2 | 2004/06/25 12:34:42 | at
>java.lang.ClassLoader.defineClass(ClassLoader.java:486)
>INFO | jvm 2 | 2004/06/25 12:34:42 | at
>java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
>INFO | jvm 2 | 2004/06/25 12:34:42 | at
>java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
>INFO | jvm 2 | 2004/06/25 12:34:42 | at
>java.net.URLClassLoader.access$100(URLClassLoader.java:56)
>INFO | jvm 2 | 2004/06/25 12:34:42 | at
>java.net.URLClassLoader$1.run(URLClassLoader.java:195)
>INFO | jvm 2 | 2004/06/25 12:34:42 | at
>java.security.AccessController.doPrivileged(Native Method)
>INFO | jvm 2 | 2004/06/25 12:34:42 | at
>java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>INFO | jvm 2 | 2004/06/25 12:34:42 | at
>java.lang.ClassLoader.loadClass(ClassLoader.java:297)
>INFO | jvm 2 | 2004/06/25 12:34:42 | at
>sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)
>INFO | jvm 2 | 2004/06/25 12:34:42 | at
>java.lang.ClassLoader.loadClass(ClassLoader.java:253)
>INFO | jvm 2 | 2004/06/25 12:34:42 | at
>java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
>INFO | jvm 2 | 2004/06/25 12:34:43 | Exception in thread "main"
>ERROR | wrapper | 2004/06/25 12:34:43 | JVM exited while loading the
>application.
>STATUS | wrapper | 2004/06/25 12:34:47 | Launching a JVM...
>INFO | jvm 3 | 2004/06/25 12:34:47 |
>java.lang.UnsupportedClassVersionError: gti/cnr/gob/sv/OC4JService
>(Unsupported major.minor version 48.0)
>INFO | jvm 3 | 2004/06/25 12:34:47 | at
>java.lang.ClassLoader.defineClass0(Native Method)
>INFO | jvm 3 | 2004/06/25 12:34:47 | at
>java.lang.ClassLoader.defineClass(ClassLoader.java:486)
>INFO | jvm 3 | 2004/06/25 12:34:47 | at
>java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
>INFO | jvm 3 | 2004/06/25 12:34:47 | at
>java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
>INFO | jvm 3 | 2004/06/25 12:34:47 | at
>java.net.URLClassLoader.access$100(URLClassLoader.java:56)
>INFO | jvm 3 | 2004/06/25 12:34:47 | at
>java.net.URLClassLoader$1.run(URLClassLoader.java:195)
>INFO | jvm 3 | 2004/06/25 12:34:47 | at
>java.security.AccessController.doPrivileged(Native Method)
>INFO | jvm 3 | 2004/06/25 12:34:47 | at
>java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>INFO | jvm 3 | 2004/06/25 12:34:47 | at
>java.lang.ClassLoader.loadClass(ClassLoader.java:297)
>INFO | jvm 3 | 2004/06/25 12:34:47 | at
>sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)
>INFO | jvm 3 | 2004/06/25 12:34:47 | at
>java.lang.ClassLoader.loadClass(ClassLoader.java:253)
>INFO | jvm 3 | 2004/06/25 12:34:47 | at
>java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
>INFO | jvm 3 | 2004/06/25 12:34:47 | Exception in thread "main"
>ERROR | wrapper | 2004/06/25 12:34:47 | JVM exited while loading the
>application.
>STATUS | wrapper | 2004/06/25 12:34:51 | Launching a JVM...
>INFO | jvm 4 | 2004/06/25 12:34:52 |
>java.lang.UnsupportedClassVersionError: gti/cnr/gob/sv/OC4JService
>(Unsupported major.minor version 48.0)
>INFO | jvm 4 | 2004/06/25 12:34:52 | at
>java.lang.ClassLoader.defineClass0(Native Method)
>INFO | jvm 4 | 2004/06/25 12:34:52 | at
>java.lang.ClassLoader.defineClass(ClassLoader.java:486)
>INFO | jvm 4 | 2004/06/25 12:34:52 | at
>java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
>INFO | jvm 4 | 2004/06/25 12:34:52 | at
>java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
>INFO | jvm 4 | 2004/06/25 12:34:52 | at
>java.net.URLClassLoader.access$100(URLClassLoader.java:56)
>INFO | jvm 4 | 2004/06/25 12:34:52 | at
>java.net.URLClassLoader$1.run(URLClassLoader.java:195)
>INFO | jvm 4 | 2004/06/25 12:34:52 | at
>java.security.AccessController.doPrivileged(Native Method)
>INFO | jvm 4 | 2004/06/25 12:34:52 | at
>java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>INFO | jvm 4 | 2004/06/25 12:34:52 | at
>java.lang.ClassLoader.loadClass(ClassLoader.java:297)
>INFO | jvm 4 | 2004/06/25 12:34:52 | at
>sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)
>INFO | jvm 4 | 2004/06/25 12:34:52 | at
>java.lang.ClassLoader.loadClass(ClassLoader.java:253)
>INFO | jvm 4 | 2004/06/25 12:34:52 | at
>java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
>INFO | jvm 4 | 2004/06/25 12:34:52 | Exception in thread "main"
>ERROR | wrapper | 2004/06/25 12:34:52 | JVM exited while loading the
>application.
>STATUS | wrapper | 2004/06/25 12:34:56 | Launching a JVM...
>INFO | jvm 5 | 2004/06/25 12:34:56 |
>java.lang.UnsupportedClassVersionError: gti/cnr/gob/sv/OC4JService
>(Unsupported major.minor version 48.0)
>INFO | jvm 5 | 2004/06/25 12:34:56 | at
>java.lang.ClassLoader.defineClass0(Native Method)
>INFO | jvm 5 | 2004/06/25 12:34:56 | at
>java.lang.ClassLoader.defineClass(ClassLoader.java:486)
>INFO | jvm 5 | 2004/06/25 12:34:56 | at
>java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
>INFO | jvm 5 | 2004/06/25 12:34:56 | at
>java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
>INFO | jvm 5 | 2004/06/25 12:34:56 | at
>java.net.URLClassLoader.access$100(URLClassLoader.java:56)
>INFO | jvm 5 | 2004/06/25 12:34:56 | at
>java.net.URLClassLoader$1.run(URLClassLoader.java:195)
>INFO | jvm 5 | 2004/06/25 12:34:56 | at
>java.security.AccessController.doPrivileged(Native Method)
>INFO | jvm 5 | 2004/06/25 12:34:56 | at
>java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>INFO | jvm 5 | 2004/06/25 12:34:56 | at
>java.lang.ClassLoader.loadClass(ClassLoader.java:297)
>INFO | jvm 5 | 2004/06/25 12:34:56 | at
>sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)
>INFO | jvm 5 | 2004/06/25 12:34:56 | at
>java.lang.ClassLoader.loadClass(ClassLoader.java:253)
>INFO | jvm 5 | 2004/06/25 12:34:56 | at
>java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
>INFO | jvm 5 | 2004/06/25 12:34:56 | Exception in thread "main"
>ERROR | wrapper | 2004/06/25 12:34:56 | JVM exited while loading the
>application.
>FATAL | wrapper | 2004/06/25 12:34:56 | There were 5 failed launches in
>a row, each lasting less than 300 seconds. Giving up.
>FATAL | wrapper | 2004/06/25 12:34:56 | There may be a configuration
>problem: please check the logs.
>STATUS | wrapper | 2004/06/25 12:34:57 | <-- Wrapper Stopped
>STATUS | wrapper | 2004/06/25 13:33:27 | --> Wrapper Started as Console
>STATUS | wrapper | 2004/06/25 13:33:27 | Launching a JVM...
>INFO | jvm 1 | 2004/06/25 13:33:28 |
>java.lang.UnsupportedClassVersionError: gti/cnr/gob/sv/OC4JService
>(Unsupported major.minor version 48.0)
>INFO | jvm 1 | 2004/06/25 13:33:28 | at
>java.lang.ClassLoader.defineClass0(Native Method)
>INFO | jvm 1 | 2004/06/25 13:33:28 | at
>java.lang.ClassLoader.defineClass(ClassLoader.java:486)
>INFO | jvm 1 | 2004/06/25 13:33:28 | at
>java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
>INFO | jvm 1 | 2004/06/25 13:33:28 | at
>java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
>INFO | jvm 1 | 2004/06/25 13:33:28 | at
>java.net.URLClassLoader.access$100(URLClassLoader.java:56)
>INFO | jvm 1 | 2004/06/25 13:33:28 | at
>java.net.URLClassLoader$1.run(URLClassLoader.java:195)
>INFO | jvm 1 | 2004/06/25 13:33:28 | at
>java.security.AccessController.doPrivileged(Native Method)
>INFO | jvm 1 | 2004/06/25 13:33:28 | at
>java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>INFO | jvm 1 | 2004/06/25 13:33:28 | at
>java.lang.ClassLoader.loadClass(ClassLoader.java:297)
>INFO | jvm 1 | 2004/06/25 13:33:28 | at
>sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)
>INFO | jvm 1 | 2004/06/25 13:33:28 | at
>java.lang.ClassLoader.loadClass(ClassLoader.java:253)
>INFO | jvm 1 | 2004/06/25 13:33:28 | at
>java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
>INFO | jvm 1 | 2004/06/25 13:33:28 | Exception in thread "main"
>ERROR | wrapper | 2004/06/25 13:33:28 | JVM exited while loading the
>application.
>STATUS | wrapper | 2004/06/25 13:33:32 | Launching a JVM...
>INFO | jvm 2 | 2004/06/25 13:33:32 |
>java.lang.UnsupportedClassVersionError: gti/cnr/gob/sv/OC4JService
>(Unsupported major.minor version 48.0)
>INFO | jvm 2 | 2004/06/25 13:33:32 | at
>java.lang.ClassLoader.defineClass0(Native Method)
>INFO | jvm 2 | 2004/06/25 13:33:32 | at
>java.lang.ClassLoader.defineClass(ClassLoader.java:486)
>INFO | jvm 2 | 2004/06/25 13:33:32 | at
>java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
>INFO | jvm 2 | 2004/06/25 13:33:32 | at
>java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
>INFO | jvm 2 | 2004/06/25 13:33:32 | at
>java.net.URLClassLoader.access$100(URLClassLoader.java:56)
>INFO | jvm 2 | 2004/06/25 13:33:32 | at
>java.net.URLClassLoader$1.run(URLClassLoader.java:195)
>INFO | jvm 2 | 2004/06/25 13:33:32 | at
>java.security.AccessController.doPrivileged(Native Method)
>INFO | jvm 2 | 2004/06/25 13:33:32 | at
>java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>INFO | jvm 2 | 2004/06/25 13:33:32 | at
>java.lang.ClassLoader.loadClass(ClassLoader.java:297)
>INFO | jvm 2 | 2004/06/25 13:33:32 | at
>sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)
>INFO | jvm 2 | 2004/06/25 13:33:33 | at
>java.lang.ClassLoader.loadClass(ClassLoader.java:253)
>INFO | jvm 2 | 2004/06/25 13:33:33 | at
>java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
>INFO | jvm 2 | 2004/06/25 13:33:33 | Exception in thread "main"
>ERROR | wrapper | 2004/06/25 13:33:33 | JVM exited while loading the
>application.
>STATUS | wrapper | 2004/06/25 13:33:37 | Launching a JVM...
>INFO | jvm 3 | 2004/06/25 13:33:37 |
>java.lang.UnsupportedClassVersionError: gti/cnr/gob/sv/OC4JService
>(Unsupported major.minor version 48.0)
>INFO | jvm 3 | 2004/06/25 13:33:37 | at
>java.lang.ClassLoader.defineClass0(Native Method)
>INFO | jvm 3 | 2004/06/25 13:33:37 | at
>java.lang.ClassLoader.defineClass(ClassLoader.java:486)
>INFO | jvm 3 | 2004/06/25 13:33:37 | at
>java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
>INFO | jvm 3 | 2004/06/25 13:33:37 | at
>java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
>INFO | jvm 3 | 2004/06/25 13:33:37 | at
>java.net.URLClassLoader.access$100(URLClassLoader.java:56)
>INFO | jvm 3 | 2004/06/25 13:33:37 | at
>java.net.URLClassLoader$1.run(URLClassLoader.java:195)
>INFO | jvm 3 | 2004/06/25 13:33:37 | at
>java.security.AccessController.doPrivileged(Native Method)
>INFO | jvm 3 | 2004/06/25 13:33:37 | at
>java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>INFO | jvm 3 | 2004/06/25 13:33:37 | at
>java.lang.ClassLoader.loadClass(ClassLoader.java:297)
>INFO | jvm 3 | 2004/06/25 13:33:37 | at
>sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)
>INFO | jvm 3 | 2004/06/25 13:33:37 | at
>java.lang.ClassLoader.loadClass(ClassLoader.java:253)
>INFO | jvm 3 | 2004/06/25 13:33:37 | at
>java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
>INFO | jvm 3 | 2004/06/25 13:33:37 | Exception in thread "main"
>ERROR | wrapper | 2004/06/25 13:33:37 | JVM exited while loading the
>application.
>STATUS | wrapper | 2004/06/25 13:33:41 | Launching a JVM...
>INFO | jvm 4 | 2004/06/25 13:33:42 |
>java.lang.UnsupportedClassVersionError: gti/cnr/gob/sv/OC4JService
>(Unsupported major.minor version 48.0)
>INFO | jvm 4 | 2004/06/25 13:33:42 | at
>java.lang.ClassLoader.defineClass0(Native Method)
>INFO | jvm 4 | 2004/06/25 13:33:42 | at
>java.lang.ClassLoader.defineClass(ClassLoader.java:486)
>INFO | jvm 4 | 2004/06/25 13:33:42 | at
>java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
>INFO | jvm 4 | 2004/06/25 13:33:42 | at
>java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
>INFO | jvm 4 | 2004/06/25 13:33:42 | at
>java.net.URLClassLoader.access$100(URLClassLoader.java:56)
>INFO | jvm 4 | 2004/06/25 13:33:42 | at
>java.net.URLClassLoader$1.run(URLClassLoader.java:195)
>INFO | jvm 4 | 2004/06/25 13:33:42 | at
>java.security.AccessController.doPrivileged(Native Method)
>INFO | jvm 4 | 2004/06/25 13:33:42 | at
>java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>INFO | jvm 4 | 2004/06/25 13:33:42 | at
>java.lang.ClassLoader.loadClass(ClassLoader.java:297)
>INFO | jvm 4 | 2004/06/25 13:33:42 | at
>sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)
>INFO | jvm 4 | 2004/06/25 13:33:42 | at
>java.lang.ClassLoader.loadClass(ClassLoader.java:253)
>INFO | jvm 4 | 2004/06/25 13:33:42 | at
>java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
>INFO | jvm 4 | 2004/06/25 13:33:42 | Exception in thread "main"
>ERROR | wrapper | 2004/06/25 13:33:42 | JVM exited while loading the
>application.
>STATUS | wrapper | 2004/06/25 13:33:46 | Launching a JVM...
>INFO | jvm 5 | 2004/06/25 13:33:46 |
>java.lang.UnsupportedClassVersionError: gti/cnr/gob/sv/OC4JService
>(Unsupported major.minor version 48.0)
>INFO | jvm 5 | 2004/06/25 13:33:46 | at
>java.lang.ClassLoader.defineClass0(Native Method)
>INFO | jvm 5 | 2004/06/25 13:33:46 | at
>java.lang.ClassLoader.defineClass(ClassLoader.java:486)
>INFO | jvm 5 | 2004/06/25 13:33:46 | at
>java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
>INFO | jvm 5 | 2004/06/25 13:33:46 | at
>java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
>INFO | jvm 5 | 2004/06/25 13:33:46 | at
>java.net.URLClassLoader.access$100(URLClassLoader.java:56)
>INFO | jvm 5 | 2004/06/25 13:33:46 | at
>java.net.URLClassLoader$1.run(URLClassLoader.java:195)
>INFO | jvm 5 | 2004/06/25 13:33:46 | at
>java.security.AccessController.doPrivileged(Native Method)
>INFO | jvm 5 | 2004/06/25 13:33:46 | at
>java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>INFO | jvm 5 | 2004/06/25 13:33:46 | at
>java.lang.ClassLoader.loadClass(ClassLoader.java:297)
>INFO | jvm 5 | 2004/06/25 13:33:46 | at
>sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)
>INFO | jvm 5 | 2004/06/25 13:33:47 | at
>java.lang.ClassLoader.loadClass(ClassLoader.java:253)
>INFO | jvm 5 | 2004/06/25 13:33:47 | at
>java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
>INFO | jvm 5 | 2004/06/25 13:33:47 | Exception in thread "main"
>ERROR | wrapper | 2004/06/25 13:33:47 | JVM exited while loading the
>application.
>FATAL | wrapper | 2004/06/25 13:33:47 | There were 5 failed launches in
>a row, each lasting less than 300 seconds. Giving up.
>FATAL | wrapper | 2004/06/25 13:33:47 | There may be a configuration
>problem: please check the logs.
>STATUS | wrapper | 2004/06/25 13:33:47 | <-- Wrapper Stopped
>
>
>Leif Mortenson wrote:
>
>  
>
>>efebo_abel wrote:
>>
>> 
>>
>>    
>>
>>>The wrapper exits without any request, help!
>>>
>>>   
>>>
>>>      
>>>
>>You are going to need to give me at least a little bit of information if you
>>expect to get any help. You have given me absolutely no information
>>making it impossible to help you even if I try.
>>
>>Please set wrapper.debug=true in your wrapper.conf file and try launching
>>your application. Then post your wrapper.conf and the contents of your
>>wrapper.log file to the wra...@li... mailing list
>>rather than to me directly.
>>
>>Cheers,
>>Leif
>>
>>
>> 
>>
>>    
>>
>
>  
>

[Wrapper-user] Re: different start/stop classes

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

Don,
I am cc-ing the wrapper-user mailing list. Please reply there and submit
any future posts to the list rather than to me directly.

Integration Method #2 does allow you to specify two different main
classes. Please reread them:
http://wrapper.tanukisoftware.org/doc/english/integrate-start-stop-win.html
The example used, Tomcat, specifies the same class for startup and
shutdown. But that is simply how Tomcat works. Your application will
be able to specify different classes.

From the docs:

# The first application parameter is the name of the class whose main
# method is to be called when the application is launched. The class
# name is followed by the number of parameters to be passed to its main
# method. Then comes the actual parameters.
wrapper.app.parameter.1=org.apache.catalina.startup.Bootstrap
wrapper.app.parameter.2=1
wrapper.app.parameter.3=start

# The start parameters are followed by the name of the class whose main
# method is to be called to stop the application. The stop class name
# is followed by a flag which controls whether or not the Wrapper should
# wait for all non daemon threads to complete before exiting the JVM.
# The flag is followed by the number of parameters to be passed to the
# stop class's main method. Finally comes the actual parameters.
wrapper.app.parameter.4=org.apache.catalina.startup.Bootstrap
wrapper.app.parameter.5=true
wrapper.app.parameter.6=1
wrapper.app.parameter.7=stop

Cheers,
Leif

Don Parker wrote:

>I am trying to use the wrappers in "integration mode 2" but 
>
>my start and stop classes are different.  It seems the 
>
>wrappers are designed to expect both functions to be 
>
>controlled from one main class.  Is there a way I can get 
>
>around this without having to implement my own 
>
>implementation for the WrapperListener?
>
>
>
>
>
>  
>

Re: [Wrapper-user] I would like to post a question to this list p lease....

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

The dependent services in the service properties page is used to specify
other services that are required by the current service. It makes sure that
those services are started before the current service is started. Likewise,
if any of those services are stopped, the current service will be stopped
first.

Note for the archives:
The second statement about stop order is not true when the machine is
shutting down. Windows is sloppy there and just shuts down all services
at the same time.

If you want to set these under the Wrapper, you can use the
wrapper.ntservice.dependency.<n> properties.

Cheers,
Leif

Stuijt, Johan wrote:

> Checkout the "services" list in windows. On the properties page, they
> mention something about "dependant" services.
>
> Maybe windows is capable of starting and stopping two or more services
> under one name.
>
> Met vriendelijke groet,
> Johan Stuijt
>
>
> -----Oorspronkelijk bericht-----
> *Van:* Ball, Kevin R [mailto:Kev...@ca...]
> *Verzonden:* dinsdag 22 juni 2004 21:53
> *Aan:* wra...@li...
> *Onderwerp:* [Wrapper-user] I would like to post a question to this
> list please....
>
> Wrapper Config to call to separate class files.
>
> I have two java components, 2 different directories: server and servlet
>
> I need to have both started via the windows services, but would like
> to have one "service name" listed. Is the "Wrapper" configurable to
> perform such a task?
>
> Thanks.
>

Re: [Wrapper-user] configuration file

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

Johan,
The environment replacement syntax on ALL platforms is %TEMP%  I had to 
choose
one or the other to be compatible across all platforms.  The Windows 
syntax was
easier parse as with the UNIX syntax $TEMP it is not possible to tell 
where the end
of the environment variable name is without looking for it.

Cheers,
Leif

Stuijt, Johan wrote:

>Thanks very much Leif,
>
>I'll check the %TEMP% directory for all the rubbish others throw around. 
>
>Btw: I try to make my wrapper config files as independent as possible, so I
>wonder, does a linux system handle %TEMP%/wrapper.log correctly, or should
>it be $TEMP/wrapper.log on a linux system? You don't have to answer that
>question, I'll just give it a go on my linux pc.
>
>Greetings from the rainy Netherlands,
>
>Johan
>  
>

RE: [Wrapper-user] I would like to post a question to this list p lease....

[Stuijt, J. <JS...@gt...>]

Checkout the "services" list in windows. On the properties page, they
mention something about "dependant" services.
Maybe windows is capable of starting and stopping two or more services under
one name.
Met vriendelijke groet, 
Johan Stuijt 
Application Engineer 
MES Expert Center 
Doorkiesnummer: 075 612 79 34 
  
GTI Industrie Noordwest bv 
        Industrial Automation 
        Houthavenkade 44  1506 PD Zaandam 
        Postbus 1377  1500 AJ Zaandam 
        tel.: 075 612 76 00   fax: 075 612 30 60 
         <http://www.gti-group.com/ia> www.gti-group.com/ia 
 
-----Oorspronkelijk bericht-----
Van: Ball, Kevin R [mailto:Kev...@ca...] 
Verzonden: dinsdag 22 juni 2004 21:53
Aan: wra...@li...
Onderwerp: [Wrapper-user] I would like to post a question to this list
please....
 
Wrapper Config to call to separate class files.
 
I have two java components, 2 different directories: server and servlet
I need to have both started via the windows services, but would like to have
one "service name" listed. Is the "Wrapper" configurable to perform such a
task? 
 
Thanks.
 
 

 
Kevin Ball 
Computer Associates 
Software Engineer 
tel: + 1 941 342-7056 
kev...@ca... <mailto:kev...@ca...>  
 
This e-mail message is for the sole use of the intended recipient(s) and may
contain confidential and/or privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all copies
of the original message.
 
================================================
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en 
is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht 
onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en 
de afzender direct te informeren door het bericht te retourneren. 
================================================
The information contained in this message may be confidential 
and is intended to be exclusively for the addressee. Should you 
receive this message unintentionally, please do not use the contents 
herein and notify the sender immediately by return e-mail.
================================================

RE: [Wrapper-user] configuration file

[Stuijt, J. <JS...@gt...>]

Thanks very much Leif,

I'll check the %TEMP% directory for all the rubbish others throw around. 

Btw: I try to make my wrapper config files as independent as possible, so I
wonder, does a linux system handle %TEMP%/wrapper.log correctly, or should
it be $TEMP/wrapper.log on a linux system? You don't have to answer that
question, I'll just give it a go on my linux pc.

Greetings from the rainy Netherlands,

Johan


================================================
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en 
is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht 
onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en 
de afzender direct te informeren door het bericht te retourneren. 
================================================
The information contained in this message may be confidential 
and is intended to be exclusively for the addressee. Should you 
receive this message unintentionally, please do not use the contents 
herein and notify the sender immediately by return e-mail.
================================================

Re: [Wrapper-user] RE: Wrapper service not automatically starting on NT

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

Stewart,
    I am not sure why it was not working for you.   I have never seen 
myself, or heard
from other users, about such problems.  It is working for you now 
however.  If you
are still concerned.  I would try uninstalling everything and then 
testing the install again.
Not sure what else to say.

Cheers,
Leif

ste...@sr... wrote:

>
> These items were checked, and it still did not work.
>
> I am not sure why, but after several uninstalls and reinstalls, via 
> the BAT file, the service finally would start at bootup.
>
> I am concerned since I do not know why it is working now, versus not 
> working earlier.  No parameter changes took place.
>
>
> Have you checked in the services control panel to see if the Startup 
> Type is set to Manual
> or Automatic?
> When you install the service (using the batch file provided with 
> JavaServiceWrapper) the
> Startup Type should be set to Automatic if 
> wrapper.ntservice.starttype=AUTO_START is in the
> wrapper.conf file. However, you can change the Startup Type yourself 
> in the Services Control
> panel and it will obey how you set it (not how it"s set in the 
> wrapper.conf file).
> I would still recommend having the value in the wrapper.conf file 
> match what you want it to
> be in case you decide to uninstall and reinstall the service later on.
>
> -Jeremy Fujimoto-Johnson
> Sr. Programmer/Analyst - eTechnology
> Adventist Health
>
> >>> stewart.meyer@sr... 6/10/04 12:52:58 PM >>>
>
>
> I am using the wrapper, on NT 2000, and it seems to be working just 
> fine, except for one
> thing.
>
> Even though the parameter is set to AUTO_START, when I install the 
> service, or reboot the
> machine, the service does not start.  I can start it manually, and it 
> works fine.
>
> Does anyone have any ideas as to why this is happening, or how I can 
> fix it.  I would
> rather it start when the machine was booted.
>
>
>
>
>
> ********************************************************
> Stewart B. Meyer
> Westinghouse Savannah River Company, LLC
> ******************************************************** 

Re: [Wrapper-user] I would like to post a question to this list please....

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

Kevin,
It is possible to run multiple Wrapper instances for each of your 
classes. Each will
have a single Java process associated with it. But it sounds like you 
would like to only
have one Wrapper process running.

The Wrapper is only capable of launching a single JVM. So directly, the
Wrapper not provide any way to launch 2 class files.

It is quite easy however. To create a small class file which has the job 
of simply
calling each of your class's main methods:

public void main( String[] args ) {
Thread t1 = new Thread( "main-1" ) {
public void run() {
Class1.main( new String[] { "param1", "param2" } );
}
};
t1.start();

Thread t2 = new Thread( "main-2" ) {
public void run() {
Class2.main( new String[] { "param1" } );
}
};
t2.start();
}

This will work for a lot of applications. But some will have problems 
because
they will both share a common working directory.

Cheers,
Leif

Ball, Kevin R wrote:

> Wrapper Config to call to separate class files.
>
> I have two java components, 2 different directories: server and servlet
>
> I need to have both started via the windows services, but would like 
> to have one “service name” listed. Is the “Wrapper” configurable to 
> perform such a task?
>
> Thanks.
>
>
> *Kevin Ball*
> Computer Associates
> Software Engineer
> tel: + 1 941 342-7056
> kev...@ca... <mailto:kev...@ca...>
>
> This e-mail message is for the sole use of the intended recipient(s) 
> and may contain confidential and/or privileged information. Any 
> unauthorized review, use, disclosure or distribution is prohibited. If 
> you are not the intended recipient, please contact the sender by reply 
> e-mail and destroy all copies of the original message.
>

[Wrapper-user] RE: Wrapper service not automatically starting on NT

[<ste...@sr...>]

These items were checked, and it still did not work.

I am not sure why, but after several uninstalls and reinstalls, via the 
BAT file, the service finally would start at bootup.

I am concerned since I do not know why it is working now, versus not 
working earlier.  No parameter changes took place.



Have you checked in the services control panel to see if the Startup Type 
is set to Manual
or Automatic? 
 When you install the service (using the batch file provided with 
JavaServiceWrapper) the
Startup Type should be set to Automatic if 
wrapper.ntservice.starttype=AUTO_START is in the
wrapper.conf file. However, you can change the Startup Type yourself in 
the Services Control
panel and it will obey how you set it (not how it"s set in the 
wrapper.conf file). 
 I would still recommend having the value in the wrapper.conf file match 
what you want it to
be in case you decide to uninstall and reinstall the service later on.
 
 -Jeremy Fujimoto-Johnson
 Sr. Programmer/Analyst - eTechnology
 Adventist Health
 
 >>> stewart.meyer@sr... 6/10/04 12:52:58 PM >>>
 
 
 I am using the wrapper, on NT 2000, and it seems to be working just fine, 
except for one
thing. 
 
 Even though the parameter is set to AUTO_START, when I install the 
service, or reboot the
machine, the service does not start.  I can start it manually, and it 
works fine. 
 
 Does anyone have any ideas as to why this is happening, or how I can fix 
it.  I would
rather it start when the machine was booted. 
 



********************************************************
Stewart B. Meyer
Westinghouse Savannah River Company, LLC
********************************************************

[Wrapper-user] I would like to post a question to this list please....

[Ball, K. R <Kev...@ca...>]

Wrapper Config to call to separate class files.

=20

I have two java components, 2 different directories: server and servlet

I need to have both started via the windows services, but would like to
have one "service name" listed. Is the "Wrapper" configurable to perform
such a task?=20

=20

Thanks.

=20

=20


=20

Kevin Ball=20
Computer Associates=20
Software Engineer=20
tel: + 1 941 342-7056=20
kev...@ca...=20

=20

This e-mail message is for the sole use of the intended recipient(s) and
may contain confidential and/or privileged information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not
the intended recipient, please contact the sender by reply e-mail and
destroy all copies of the original message.

=20

Re: [Wrapper-user] Truncated log entries

[Rick S. <rs...@as...>]

Leif,
   Some of our messages are pretty large(ie Base64 encoding of images, 
don't ask... :-[ ).
I think it is quite reasonable for there to be a fixed limit. I would 
propose 2048 or 4096
characters even. I would hazard to guess that performance would not 
degrade too badly
given a larger fixed buffer.

What do you think?

Rick

Leif Mortenson wrote:

> Rick,
>    Currently for performance reasons, a fixed buffer is used when 
> reading the JVM
> output.   The way it is implemented, this causes a linefeed each 1024 
> characters
> for very long lines.   There is not a way to change this behavior in 
> the current release.
> I will look into getting that cleaned up.   It has been a minor 
> annoyance in a couple
> of my applications as well.
>    At some point, I want to make the buffer dynamically scale.  But I 
> am trying to
> get a release out.  If it is within reason, I can quickly up the size 
> a bit.  How long are
> the lines you are trying to log?
>
>    Glad to hear we are helping with mental health in our own little 
> way. :-)
>
> Cheers,
> Leif
>
> Rick Szeto wrote:
>
>> Hi all,
>>  I am experiencing long logs entries to the console logfile being 
>> truncated. Is there a configuration parameter I missing that will fix 
>> this? Or is this a know problem?
>>
>> Any help would be greatly appricated.
>>
>> BTW, the wrapper is the only thing that is keeping me sane in our 
>> production environment.
>> Thanks.
>>
>> Rick Szeto
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital 
> self defense, top technical experts, no vendor pitches, unmatched 
> networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
> .
>

Re: [Wrapper-user] Truncated log entries

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

Rick,
    Currently for performance reasons, a fixed buffer is used when 
reading the JVM
output.   The way it is implemented, this causes a linefeed each 1024 
characters
for very long lines.   There is not a way to change this behavior in the 
current release.
I will look into getting that cleaned up.   It has been a minor 
annoyance in a couple
of my applications as well.
    At some point, I want to make the buffer dynamically scale.  But I 
am trying to
get a release out.  If it is within reason, I can quickly up the size a 
bit.  How long are
the lines you are trying to log?

    Glad to hear we are helping with mental health in our own little 
way. :-)

Cheers,
Leif

Rick Szeto wrote:

> Hi all,
>  I am experiencing long logs entries to the console logfile being 
> truncated. Is there a configuration parameter I missing that will fix 
> this? Or is this a know problem?
>
> Any help would be greatly appricated.
>
> BTW, the wrapper is the only thing that is keeping me sane in our 
> production environment.
> Thanks.
>
> Rick Szeto

[Wrapper-user] Truncated log entries

[Rick S. <rs...@as...>]

Hi all,
  I am experiencing long logs entries to the console logfile being 
truncated. Is there a configuration parameter I missing that will fix 
this? Or is this a know problem?

Any help would be greatly appricated.

BTW, the wrapper is the only thing that is keeping me sane in our 
production environment.
Thanks.

Rick Szeto