|
From: Venkatesh S. <Ven...@lc...> - 2004-06-30 08:50:02
|
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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
**********************************************************************
|