wrapper-user

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

[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

[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.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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 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] 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>