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

Re: [Wrapper-user] JVM Exited Unexpectedly

[no s. <mrs...@gm...>]

hmmm ... i just figured out that compiled with JRE 1.5.0_06 and was
interpreting with 1.6.0_03-b05.  Would this cause issues like this?

On 11/9/07, no spam <mrs...@gm...> wrote:
>
> I forgot to include my platform information
>
> Windows Server 2003 Standard, Version 5.2.3790 Service Pack 2 Build 3790
> JRE 1.6.0_03-b05
>
> Mark
>
>

Re: [Wrapper-user] JVM Exited Unexpectedly

[no s. <mrs...@gm...>]

I forgot to include my platform information

Windows Server 2003 Standard, Version 5.2.3790 Service Pack 2 Build 3790
JRE 1.6.0_03-b05

Mark

[Wrapper-user] JVM Exited Unexpectedly

[no s. <mrs...@gm...>]

I have a process that's using cpu very heavily.  In fact the graph
hovers around 80-100%.  I'm running a performance test of my software
before we release it to the newsroom at CNN.  However about 36 hours
into the test I see the errors below: "JVM exited unexpectedly".  It's
confusing because I don't see any crashes via Dr Watson nor any logs.

My ping is also set high (20 minutes) because the previous setting of
10 minutes apparently wasn't responsive enough.

Any ideas?


ERROR  | wrapper  | 2007/11/09 00:30:08 | JVM exited unexpectedly.
STATUS | wrapper  | 2007/11/09 00:30:12 | Launching a JVM...
INFO   | jvm 2    | 2007/11/09 00:30:13 | Wrapper (Version 3.2.3)
http://wrapper.tanukisoftware.org
INFO   | jvm 2    | 2007/11/09 00:30:13 |   Copyright 1999-2006 Tanuki
Software, Inc.  All Rights Reserved.
INFO   | jvm 2    | 2007/11/09 00:30:13 |
INFO   | jvm 2    | 2007/11/09 00:32:06 |
INFO   | jvm 2    | 2007/11/09 00:32:06 |
INFO   | jvm 2    | 2007/11/09 00:32:06 | J-Integra 2.5  Copyright (C)
1998-2005 Intrinsyc Software International, Inc. http://j-integra.int
rinsyc.com/
INFO   | jvm 2    | 2007/11/09 00:32:06 |
INFO   | jvm 2    | 2007/11/09 00:32:06 |
***************************************************
INFO   | jvm 2    | 2007/11/09 00:32:06 |
INFO   | jvm 2    | 2007/11/09 00:32:06 | Thank you for choosing J-Integra.
INFO   | jvm 2    | 2007/11/09 00:32:06 | Please visit
http://j-integra.intrinsyc.com/ for
INFO   | jvm 2    | 2007/11/09 00:32:06 | documentation, support, and
purchasing information.
INFO   | jvm 2    | 2007/11/09 00:32:06 |
INFO   | jvm 2    | 2007/11/09 00:32:06 |
***************************************************
INFO   | jvm 2    | 2007/11/09 00:32:06 |
INFO   | jvm 2    | 2007/11/09 00:32:06 |
ERROR  | wrapper  | 2007/11/09 06:00:10 | JVM exited unexpectedly.
STATUS | wrapper  | 2007/11/09 06:00:14 | Launching a JVM...
INFO   | jvm 3    | 2007/11/09 06:00:15 | Wrapper (Version 3.2.3)
http://wrapper.tanukisoftware.org
"treatment/log/wrapper_treatment-20071109.log" [dos format] 227 lines,
18540 characters

Re: [Wrapper-user] Unable to execute Wrapper

[Jay S. <jay...@al...>]

Thanks=20Philip


________________________________________________________________________
This=20e-mail=20has=20been=20scanned=20for=20all=20viruses=20by=20Star.=20=
The
service=20is=20powered=20by=20MessageLabs.=20For=20more=20information=20on=
=20a=20proactive
anti-virus=20service=20working=20around=20the=20clock,=20around=20the=20gl=
obe,=20visit:
http://www.star.net.uk
________________________________________________________________________

Re: [Wrapper-user] Can't get to work.

[Wadi J. M. <wa...@ya...>]

Ok, I'll try it again this days, Thanks for the response.=0AWadi=0A=0A=0A--=
--- Mensaje original ----=0ADe: Leif Mortenson <le...@ta...>=0A=
Para: wra...@li...=0AEnviado: mi=C3=A9rcoles 7 de nov=
iembre de 2007, 1:51:25=0AAsunto: Re: [Wrapper-user] Can't get to work.=0A=
=0AWadi,=0AFor Integration Methods #1 and #2, there is no need to write any=
=0AJava code for the Wrapper.  It can be done purely with a configuration=
=0Afile.=0Ahttp://wrapper.tanukisoftware.org/doc/english/integrate.html=0A=
=0AIf you need to do more advanced things, you can access the=0AWrapperMana=
ger class from within your code using Method #1 or 2.=0A=0AFor completely c=
ustom integrations, you can look at Method #3.  But=0AI DO NOT advise this =
until you know you absolutely need it.=0A=0AMethod #1 will work for 95% of =
users and #2 for most of the rest.=0A=0AIf you are still having problems af=
ter reading the above=0Adocumentation, I will need to see your wrapper.conf=
 and the=0Aoutput of your wrapper.log to be able to help further.=0A=0AChee=
rs,=0ALeif=0A=0AWadi Jalil Maluf wrote:=0A> Hi All! I'm trying to make a NT=
 service but I follow the steps on the =0A> page and I can't get it to work=
. Can any one give me an example on how =0A> the java code should be introd=
uced into the app with the =0A> WrapperSimpleApp? Cause I had been searchin=
g but there is no doc with =0A> examples about that.=0A> Thanks in advance,=
=0A> Regards,=0A> Wadi=0A=0A=0A--------------------------------------------=
-----------------------------=0AThis SF.net email is sponsored by: Splunk I=
nc.=0AStill grepping through log files to find problems?  Stop.=0ANow Searc=
h log events and configuration files using AJAX and a browser.=0ADownload y=
our FREE copy of Splunk now >> http://get.splunk.com/=0A___________________=
____________________________=0AWrapper-user mailing list=0AWrapper-user@lis=
ts.sourceforge.net=0Ahttps://lists.sourceforge.net/lists/listinfo/wrapper-u=
ser=0A=0A=0A      Compart=C3=AD video en la ventana de tus mensajes (y tamb=
i=C3=A9n tus fotos de Flickr). =0AUs=C3=A1 el nuevo Yahoo! Messenger versi=
=C3=B3n Beta. http://ar.beta.messenger.yahoo.com/

Re: [Wrapper-user] Can't get to work.

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

Wadi,
For Integration Methods #1 and #2, there is no need to write any
Java code for the Wrapper.  It can be done purely with a configuration
file.
http://wrapper.tanukisoftware.org/doc/english/integrate.html

If you need to do more advanced things, you can access the
WrapperManager class from within your code using Method #1 or 2.

For completely custom integrations, you can look at Method #3.  But
I DO NOT advise this until you know you absolutely need it.

Method #1 will work for 95% of users and #2 for most of the rest.

If you are still having problems after reading the above
documentation, I will need to see your wrapper.conf and the
output of your wrapper.log to be able to help further.

Cheers,
Leif

Wadi Jalil Maluf wrote:
> Hi All! I'm trying to make a NT service but I follow the steps on the 
> page and I can't get it to work. Can any one give me an example on how 
> the java code should be introduced into the app with the 
> WrapperSimpleApp? Cause I had been searching but there is no doc with 
> examples about that.
> Thanks in advance,
> Regards,
> Wadi

Re: [Wrapper-user] Runtime exec in my app fails when app is installed as a service

[Gesly G. <ges...@gm...>]

>
> Nathan,


Thanks for your reply. It looks like the Network drive is the problem.  I
will have to make sure that the service accesses the local drives only.

THanks


> Message: 5
> Date: Mon, 5 Nov 2007 16:39:28 -0500
> From: "Nathan Wray" <wr...@de...>
> Subject: Re: [Wrapper-user] Runtime exec in my app fails when app is
>        installed as a service
> To: wra...@li...
> Message-ID:
>        <aeb...@ma...>
> Content-Type: text/plain; charset="utf-8"
>
> If possible, I suggest you test with your network-drive content copied
> locally.  I've had problems in the past with services and mapped drives
> under windows, it would be a useful debugging step to eliminate this as
> your
> problem before looking elsewhere.  Even running the service as a user that
> has the drives mapped on login will generally not work.  There are a lot
> of
> discussions about this problem elsewhere online.
>
> Nathan
>
> On 11/5/07, Gesly George <ges...@gm...> wrote:
> >
> > Hi,
> >
> > My Java app (Jar1.MainClass) calls Rumtime.exec() to execute another
> java
> > app (jar2.MainClass). This works when I run the app from the command
> line
> > (hence I would assume my Rumtime.exec() is working properly). It
> > successfully execs the new process.
> >
> > But when I wrap the app (inside the java service wrapper, the app (
> > jar1.MainClass) starts up fine, but the Rumtime.exec() fails. My app
> gets
> > a NoClassDefFoundError on the call to the Runtime.exec() - Its not able
> to
> > find the main class of the process that my App is trying to exec(). What
> > intrigues me if how does wrapping my app in a service differ from
> running
> > the app from the command line. The service is not failing since it runs
> my
> > app ( jar1.MainClass), but somehow it fails on the exec.
> >
> > I have tried the following:
> > - Since my path includes a network drive, I thought the problem might be
> > related to security - so I run the service as a permissioned user
> instead of
> > the default system user.
> > - Since this could be a classpath problem I added the jar to wrapper's
> > classpath in the conf file.
> >
> > I searched the website, but could not find something that would help me
> > solve the problem. It would be great if any of you have a suggestion for
> > this.
> >
> > Thanks
> > Gesly
> >
> >
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > Wrapper-user mailing list
> > Wra...@li...
> > https://lists.sourceforge.net/lists/listinfo/wrapper-user
> >
> >
>
>
> --
> Nathan Wray
> nw...@de...
> --
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
>
> ------------------------------
>
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>
> End of Wrapper-user Digest, Vol 18, Issue 1
> *******************************************
>



-- 
Gesly Abraham George

[Wrapper-user] Can't get to work.

[Wadi J. M. <wa...@ya...>]

Hi All! I'm trying to make a NT service but I follow the steps on the page =
and I can't get it to work. Can any one give me an example on how the java =
code should be introduced into the app with the WrapperSimpleApp? Cause I h=
ad been searching but there is no doc with examples about that.=0AThanks in=
 advance,=0ARegards,=0AWadi=0A=0A=0A      Compart=C3=AD video en la ventana=
 de tus mensajes (y tambi=C3=A9n tus fotos de Flickr). =0AUs=C3=A1 el nuevo=
 Yahoo! Messenger versi=C3=B3n Beta. http://ar.beta.messenger.yahoo.com/

Re: [Wrapper-user] Runtime exec in my app fails when app is installed as a service

[Hubert F. <Hub...@ab...>]

Hi,

If possible try to avoid using the redirector from a service. You won't =
get lucky with this.
One of your problems is, that services running with localsystem account =
cannot access the the redirector (network).=20
-You would have to establisch a "null session share" to the target =
machine. That't means absolutely no security. Otherwise=20
you must run the service with a dedicated user account.=20
-Your service has to be dependant on Windows Server service and Workstation=
 service  to wait for the network first.
-You have problems mapping the drive while a user is logged in.
-You loose that drive as soon as the user logs out.
-You'd have to enumerate the user shares to find the relation from mapped =
network drive to the share name. If you cannot avoid it, you should use
UNC names instead of drive letters.

I would do it in another way, if possible.

hub

>>> "Gesly George" <ges...@gm...> 05.11.2007 22:26 >>>
Hi,

My Java app (Jar1.MainClass) calls Rumtime.exec() to execute another java
app (jar2.MainClass). This works when I run the app from the command line
(hence I would assume my Rumtime.exec() is working properly). It
successfully execs the new process.

But when I wrap the app (inside the java service wrapper, the app (
jar1.MainClass) starts up fine, but the Rumtime.exec() fails. My app gets =
a
NoClassDefFoundError on the call to the Runtime.exec() - Its not able to
find the main class of the process that my App is trying to exec(). What
intrigues me if how does wrapping my app in a service differ from running
the app from the command line. The service is not failing since it runs my
app (jar1.MainClass), but somehow it fails on the exec.

I have tried the following:
- Since my path includes a network drive, I thought the problem might be
related to security - so I run the service as a permissioned user instead =
of
the default system user.
- Since this could be a classpath problem I added the jar to wrapper's
classpath in the conf file.

I searched the website, but could not find something that would help me
solve the problem. It would be great if any of you have a suggestion for
this.

Thanks
Gesly

Re: [Wrapper-user] Runtime exec in my app fails when app is installed as a service

[Nathan W. <wr...@de...>]

If possible, I suggest you test with your network-drive content copied
locally.  I've had problems in the past with services and mapped drives
under windows, it would be a useful debugging step to eliminate this as your
problem before looking elsewhere.  Even running the service as a user that
has the drives mapped on login will generally not work.  There are a lot of
discussions about this problem elsewhere online.

Nathan

On 11/5/07, Gesly George <ges...@gm...> wrote:
>
> Hi,
>
> My Java app (Jar1.MainClass) calls Rumtime.exec() to execute another java
> app (jar2.MainClass). This works when I run the app from the command line
> (hence I would assume my Rumtime.exec() is working properly). It
> successfully execs the new process.
>
> But when I wrap the app (inside the java service wrapper, the app (
> jar1.MainClass) starts up fine, but the Rumtime.exec() fails. My app gets
> a NoClassDefFoundError on the call to the Runtime.exec() - Its not able to
> find the main class of the process that my App is trying to exec(). What
> intrigues me if how does wrapping my app in a service differ from running
> the app from the command line. The service is not failing since it runs my
> app ( jar1.MainClass), but somehow it fails on the exec.
>
> I have tried the following:
> - Since my path includes a network drive, I thought the problem might be
> related to security - so I run the service as a permissioned user instead of
> the default system user.
> - Since this could be a classpath problem I added the jar to wrapper's
> classpath in the conf file.
>
> I searched the website, but could not find something that would help me
> solve the problem. It would be great if any of you have a suggestion for
> this.
>
> Thanks
> Gesly
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>


-- 
Nathan Wray
nw...@de...
--

[Wrapper-user] Runtime exec in my app fails when app is installed as a service

[Gesly G. <ges...@gm...>]

Hi,

My Java app (Jar1.MainClass) calls Rumtime.exec() to execute another java
app (jar2.MainClass). This works when I run the app from the command line
(hence I would assume my Rumtime.exec() is working properly). It
successfully execs the new process.

But when I wrap the app (inside the java service wrapper, the app (
jar1.MainClass) starts up fine, but the Rumtime.exec() fails. My app gets a
NoClassDefFoundError on the call to the Runtime.exec() - Its not able to
find the main class of the process that my App is trying to exec(). What
intrigues me if how does wrapping my app in a service differ from running
the app from the command line. The service is not failing since it runs my
app (jar1.MainClass), but somehow it fails on the exec.

I have tried the following:
- Since my path includes a network drive, I thought the problem might be
related to security - so I run the service as a permissioned user instead of
the default system user.
- Since this could be a classpath problem I added the jar to wrapper's
classpath in the conf file.

I searched the website, but could not find something that would help me
solve the problem. It would be great if any of you have a suggestion for
this.

Thanks
Gesly

[Wrapper-user] JVM appears hung: Timed out waiting for signal from JVM on AIX 5.3

[Mayes, R. <Reb...@G1...>]

I have the same problem many others seem to have- the wrapper sometimes
doesn't get a response from the JVM within the timeout period, so it
shuts it down:

 

JVM appears hung: Timed out waiting for signal from JVM.

JVM did not exit on request, terminated

 

>From everything I've read on the web, the solutions are:

1.	Extend the timeout period (risking a longer hang when there's a
"real" problem)
2.	Do what you can to make sure the JVM is not overburdened.

 

My questions are:

1.	We predominantly see this on AIX. Is there some special problem
with IBM's JVM and the wrapper? We have Java 1.5  SR4 on our test
machine and I am going to try updating it to the latest (SR6) today.
2.	Will reducing the memory allocated to Java help? Currently,
we're using wrapper.java.initmemory=1024 and wrapper.java.maxmemory=1024
on a box with 1.8 GB of RAM.
3.	Any other suggestions?

 

Thanks!

Rebecca Mayes

Manager of CDQ/DI Quality Assurance

Pitney Bowes Software 
 
NOTICE: This E-mail may contain confidential information. If you are not
the addressee or the intended recipient please do not read this E-mail
and please immediately delete this e-mail message and any attachments
from your workstation or network mail system. If you are the addressee
or the intended recipient and you save or print a copy of this E-mail,
please place it in an appropriate file, depending on whether
confidential information is contained in the message.

Re: [Wrapper-user] Second integration method question

[Marcin W. <mwa...@su...>]

Thanks for your answer :)

Regards,
Marcin

Leif Mortenson wrote:
> Marcin,
> Sorry, the Wrapper does not do anything fancy with class loaders or
> anything else as that would have consequences for other applications.
> It looks like Geronimo is not going to work as is.   It should be very
> easy to modify it so it would work with either method 1 or method 2
> smoothly.  Some applications even go as far as to support method 3
> directly.
> 
> Cheers,
> Leif
> 

[Wrapper-user] RES: Problems with wrapper and Windows

[Juliana J. L. <Ju...@ms...>]

Leif,

The problem happened again. I can't reproduce it...
The wrapper version I'm using is 3.1.2.
I enabled debug and i'm waiting for the problem to happen again.

Thanks,
Juliana.

-----Mensagem original-----
De: Leif Mortenson [mailto:le...@ta...]
Enviada em: quarta-feira, 26 de setembro de 2007 19:52
Para: wra...@li...
Assunto: Re: [Wrapper-user] Problems with wrapper and Windows [XW-SPAM -
heur][XW-SPAM - mx]


Juliana,
What version of the Wrapper are you using?

Is this something you are able to reproduce?  If so, try running it with
wrapper.debug enabled.  Seeing more precisely where it crashed
would give me something to go on.

Leif

Juliana Jacques Leroy wrote:
> Hi all,
>
> Sometimes the wrapper.exe is canceling with windows. I get this error =
in the EventViewer:
>
> =
-------------------------------------------------------------------------=
------------------------------------------------------------------------
> Event Type: Information
> Event Source: DrWatson
> Event Category: None
> Event ID: 4097
> Date: 26/9/2007
> Time: 14:36:00
> User: N/A
> Computer: SCX340242
> Description:
> The application, C:\SADSXP\TelnetDService\bin\wrapper.exe, generated =
an application error The error occurred on 09/26/2007 @ 14:35:58.041 The =
exception generated was c0000005 at address 0040E42A (wrapper)
> =
-------------------------------------------------------------------------=
------------------------------------------------------------------------
>
> Any ideas?
> I'm running Windows Server 2003 Enterprise Edition.
>
> Thanks,
> Juliana.


-------------------------------------------------------------------------=

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] JVM appears hung: VMware, verbose garbage collection

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

Nathan,
The batch file idea is unfortunately not going to work.  The Wrapper
expects that a JVM will be launched.   It doesn't help now, but I have
been working on the ability to launch external processes in response
to various Wrapper and JVM lifecycle events.

For now, I would suggest changing the main class that you are
passing to the WrapperSimpleApp helper class with a simple
class that does the clean up work for you.  The last line of that
class's main method would simply call the main method of your
real application.

This will let you do the necessary cleanup before the actual
application attempts to initialize itself.

public class StartupHelper
{
    private static void doMyCleanup()
    {
        // ...
    }

    public static void main( String args[] )
    {
        doMyCleanup();

        RealMainClass.main( args );
    }
}

Cheers,
Leif

Nathan Wray wrote:
> Thanks Leif, we're running the ping timeout now at a higher value 
> (360).  We dropped it to 10 trying to force the wrapper to kill the 
> process, trying to figure out why it was never doing a clean shutdown. 
> Now that it is clear the shutdown will always be a hard kill we can 
> stop that testing. 
>
> We're still stuck with a server that cannot be started after a hard 
> kill though.  After a hard kill, the server process starts but the 
> application configuration files, etc are all missing, and it just 
> fails along uselessly.  When we stop the server and clean up the temp 
> folders it's all fine, and when the server is started and stopped 
> normally it's fine.  But we cannot seem to survive a hard shutdown.  
> We're looking at ways to add a batch script to be called before the 
> server is started, so we can clean up the temp folder.  One idea that 
> seems promising is to replace the wrapper.java.command with a batch 
> file that first cleans the temp folder and then calls java.  Do you 
> have any other suggestions for hooking into application startup?
>
> The batch file would be similar to this:
>
> IF EXIST "%JBOSS_HOME%\server\default
> \tmp" (
>   rmdir /S /Q "%JBOSS_HOME%\server\default\tmp"
> )
>
> "%JAVA_HOME%\bin\java" %*
>
> Thanks again for your help Leif
> Nathan
>
>
> On 10/29/07, *Leif Mortenson* <le...@ta... 
> <mailto:le...@ta...>> wrote:
>
>     Nathan,
>     Java does indeed appear frozen if its memory gets swapped to disk
>     or during long GC cycles.    To an outside process, the JVM is indeed
>     frozen while either event happens.
>
>     Looking at the wrapper.conf that you posted, you have your
>     wrapper.ping.timeout set to 10 seconds.  Why did you set it to a
>     value shorter than the default of 30 seconds?  My first suggestion
>     would be to set the timeout to 60 or 120 seconds and see how that
>     works for you.
>
>     An old version of the Wrapper started to shutdown cleanly when
>     a ping timeout was encountered.  But if the JVM is really frozen,
>     the shutdown would of course still fail.   If the JVM was not really
>     frozen then the JVM would still either be shutdown or killed.  If
>     the "frozen" state is an artifact of GC or of memory swapping, then
>     a better solution is to increase the ping timeout.
>
>     I have used the Wrapper under VMWare quite a bit.  But not in
>     cases where the JVM or VM were under heavy loads.  I have seen
>     problems when the host OS is under heavy loads, but that is not
>     surprising as VMWare becomes pretty doggish under those
>     circumstances.
>
>     One thing that greatly improved the VMWare performance in cases
>     where the host OS was under load was to disable VMWare from
>     allowing the VM's memory to be swapped.  Force it to stay in active
>     memory.  That gets rid of the long freezes.
>
>     Cheers,
>     Leif
>
>     Nathan Wray wrote:
>     >
>     > Hi;
>     >
>     > I have an application being deployed onto JBoss on Windows under
>     > VMware.  JBoss is running as a service under wrapper.
>     > Although the application has run elsewhere for long periods of time
>     > with no issues, we're seeing a problem under wrapper.
>     > Once the app has been running for 1-2 hours, we see:
>     >
>     > ERROR  | wrapper  | 2007/10/26 16:25:17 | JVM appears hung:
>     Timed out
>     > waiting for signal from JVM.
>     > ERROR  | wrapper  | 2007/10/26 16:25:18 | JVM did not exit on
>     request,
>     > terminated
>     >
>     > Our app is deployed as an EAR file, and if the JBoss server process
>     > doesn't shut down cleanly it won't come back up without deleting
>     the
>     > tmp, work and data folders.  So once wrapper has gunned the server
>     > it's dead until someone manually intervenes.
>     >
>     > Using the default ticks timer we see messages like this
>     periodically:
>     >
>     >  The timer fell behind the system clock by 14600ms.
>     >
>     > Our server is a VMware instance, so it is possible that the VM could
>     > be getting swapped out or starved.  This would probably appear
>     to an
>     > application as though the clock and timers were jumping out of
>     sync in
>     > ways that normally are impossible.
>     > Is anyone successfully using wrapper under VMware?
>     >
>     > Also we're running with verbose garbage collection, which I
>     understand
>     > can hang the server momentarily.  Are there known issues with
>     verbose
>     > garbage collection under wrapper?
>     >
>     > Looking through the code it doesn't appear that wrapper tries to
>     shut
>     > down the server once it decides there is a hang; it looks like
>     it goes
>     > right into WRAPPER_JSTATE_KILLING rather than
>     WRAPPER_JSTATE_STOPPING;
>     > so that the shutdownTimeout parameter does not come into
>     play.  Would
>     > it be possible to attempt a clean shutdown before killing the
>     server?
>     >
>     >
>     > Selected settings below.  Note right now we're trying to address the
>     > hard kill that leaves the server unusable, we will eventually
>     bump up
>     > the ping timeout to try and avoid the kill in the first place.
>     >
>     > # Number of seconds between Wrapper ping requests to the JVM.
>     > wrapper.ping.interval=5
>     >
>     > #Number of seconds to allow between the wrapper pinging the JVM and
>     > the response.
>     > wrapper.ping.timeout=10
>     >
>     > #Number of seconds between JVM reports stopped and the JVM actually
>     > terminates.
>     > wrapper.jvm_exit.timeout=60
>     > wrapper.shutdown.timeout=60
>     > wrapper.restart.delay=60
>     >
>     > wrapper.timer_fast_threshold=0
>     > wrapper.timer_slow_threshold=10
>     >
>     > # Force reload of wrapper config on JVM restart
>     > wrapper.restart.reload_configuration=TRUE
>     >
>     > Thanks for any insight you can bring.
>     >
>     > Nathan
>
>
>     -------------------------------------------------------------------------
>     This SF.net email is sponsored by: Splunk Inc.
>     Still grepping through log files to find problems?  Stop.
>     Now Search log events and configuration files using AJAX and a
>     browser.
>     Download your FREE copy of Splunk now >> http://get.splunk.com/
>     _______________________________________________
>     Wrapper-user mailing list
>     Wra...@li...
>     <mailto:Wra...@li...>
>     https://lists.sourceforge.net/lists/listinfo/wrapper-user
>     <https://lists.sourceforge.net/lists/listinfo/wrapper-user>
>
>
>
>
> -- 
> Nathan Wray
> nw...@de... <mailto:nw...@de...>
> -- 
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>   

Re: [Wrapper-user] JVM appears hung: VMware, verbose garbage collection

[Nathan W. <wr...@de...>]

Thanks Leif, we're running the ping timeout now at a higher value (360).  We
dropped it to 10 trying to force the wrapper to kill the process, trying to
figure out why it was never doing a clean shutdown.
Now that it is clear the shutdown will always be a hard kill we can stop
that testing.

We're still stuck with a server that cannot be started after a hard kill
though.  After a hard kill, the server process starts but the application
configuration files, etc are all missing, and it just fails along
uselessly.  When we stop the server and clean up the temp folders it's all
fine, and when the server is started and stopped normally it's fine.  But we
cannot seem to survive a hard shutdown.  We're looking at ways to add a
batch script to be called before the server is started, so we can clean up
the temp folder.  One idea that seems promising is to replace the
wrapper.java.command with a batch file that first cleans the temp folder and
then calls java.  Do you have any other suggestions for hooking into
application startup?

The batch file would be similar to this:

IF EXIST "%JBOSS_HOME%\server\default\tmp" (
  rmdir /S /Q "%JBOSS_HOME%\server\default\tmp"
)

"%JAVA_HOME%\bin\java" %*

Thanks again for your help Leif
Nathan


On 10/29/07, Leif Mortenson <le...@ta...> wrote:
>
> Nathan,
> Java does indeed appear frozen if its memory gets swapped to disk
> or during long GC cycles.    To an outside process, the JVM is indeed
> frozen while either event happens.
>
> Looking at the wrapper.conf that you posted, you have your
> wrapper.ping.timeout set to 10 seconds.  Why did you set it to a
> value shorter than the default of 30 seconds?  My first suggestion
> would be to set the timeout to 60 or 120 seconds and see how that
> works for you.
>
> An old version of the Wrapper started to shutdown cleanly when
> a ping timeout was encountered.  But if the JVM is really frozen,
> the shutdown would of course still fail.   If the JVM was not really
> frozen then the JVM would still either be shutdown or killed.  If
> the "frozen" state is an artifact of GC or of memory swapping, then
> a better solution is to increase the ping timeout.
>
> I have used the Wrapper under VMWare quite a bit.  But not in
> cases where the JVM or VM were under heavy loads.  I have seen
> problems when the host OS is under heavy loads, but that is not
> surprising as VMWare becomes pretty doggish under those
> circumstances.
>
> One thing that greatly improved the VMWare performance in cases
> where the host OS was under load was to disable VMWare from
> allowing the VM's memory to be swapped.  Force it to stay in active
> memory.  That gets rid of the long freezes.
>
> Cheers,
> Leif
>
> Nathan Wray wrote:
> >
> > Hi;
> >
> > I have an application being deployed onto JBoss on Windows under
> > VMware.  JBoss is running as a service under wrapper.
> > Although the application has run elsewhere for long periods of time
> > with no issues, we're seeing a problem under wrapper.
> > Once the app has been running for 1-2 hours, we see:
> >
> > ERROR  | wrapper  | 2007/10/26 16:25:17 | JVM appears hung: Timed out
> > waiting for signal from JVM.
> > ERROR  | wrapper  | 2007/10/26 16:25:18 | JVM did not exit on request,
> > terminated
> >
> > Our app is deployed as an EAR file, and if the JBoss server process
> > doesn't shut down cleanly it won't come back up without deleting the
> > tmp, work and data folders.  So once wrapper has gunned the server
> > it's dead until someone manually intervenes.
> >
> > Using the default ticks timer we see messages like this periodically:
> >
> >  The timer fell behind the system clock by 14600ms.
> >
> > Our server is a VMware instance, so it is possible that the VM could
> > be getting swapped out or starved.  This would probably appear to an
> > application as though the clock and timers were jumping out of sync in
> > ways that normally are impossible.
> > Is anyone successfully using wrapper under VMware?
> >
> > Also we're running with verbose garbage collection, which I understand
> > can hang the server momentarily.  Are there known issues with verbose
> > garbage collection under wrapper?
> >
> > Looking through the code it doesn't appear that wrapper tries to shut
> > down the server once it decides there is a hang; it looks like it goes
> > right into WRAPPER_JSTATE_KILLING rather than WRAPPER_JSTATE_STOPPING;
> > so that the shutdownTimeout parameter does not come into play.  Would
> > it be possible to attempt a clean shutdown before killing the server?
> >
> >
> > Selected settings below.  Note right now we're trying to address the
> > hard kill that leaves the server unusable, we will eventually bump up
> > the ping timeout to try and avoid the kill in the first place.
> >
> > # Number of seconds between Wrapper ping requests to the JVM.
> > wrapper.ping.interval=5
> >
> > #Number of seconds to allow between the wrapper pinging the JVM and
> > the response.
> > wrapper.ping.timeout=10
> >
> > #Number of seconds between JVM reports stopped and the JVM actually
> > terminates.
> > wrapper.jvm_exit.timeout=60
> > wrapper.shutdown.timeout=60
> > wrapper.restart.delay=60
> >
> > wrapper.timer_fast_threshold=0
> > wrapper.timer_slow_threshold=10
> >
> > # Force reload of wrapper config on JVM restart
> > wrapper.restart.reload_configuration=TRUE
> >
> > Thanks for any insight you can bring.
> >
> > Nathan
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>



-- 
Nathan Wray
nw...@de...
--

Re: [Wrapper-user] Second integration method question

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

Marcin,
Sorry, the Wrapper does not do anything fancy with class loaders or
anything else as that would have consequences for other applications.
It looks like Geronimo is not going to work as is.   It should be very
easy to modify it so it would work with either method 1 or method 2
smoothly.  Some applications even go as far as to support method 3
directly.

Cheers,
Leif

Marcin Waldowski wrote:
> Leif Mortenson wrote:
>   
>> Marcin,
>> Without using the wrapper, many applications launch a second JVM
>> instance simply to trigger the shutdown of the first.  This is usually
>> done by deleting an anchor file or sending a command via a socket.
>> The wrapper makes this much lighter by running this shutdown
>> code in the same JVM.
>>     
>
> Yes, and this is OK! :)
>
>   
>> Are you having problems running the shudown class in the same
>> JVM? 
>>     
>
> Yes, in case of Geronimo it result with IllegalStateException.
>
> In "start" class we have execution of:
>      KernelRegistry.registerKernel("MainBootstrapper");
> and in "stop" class we have execution of the same:
>      KernelRegistry.registerKernel("MainBootstrapper");
> which in "stop" class result with
>      java.lang.IllegalStateException: A kernel is already running this 
> kernel
>
> You can see discusion about it here:
> http://www.mail-archive.com/us...@ge.../msg07665.html
> Result of discussion is that it is *intended* to run shutdown class in a 
> different vm. It means that second integration method can not be used 
> (only first can be used) for Geronimo.
>
> Of course the best solution is to modify Geronimo shutdown class. But 
> first I decided to ask You if it is posible to do some trick to make it 
> works in second integration method ;)
>
> I'm *not* trying to tell you that it's worth to implement calling "stop" 
> class in different vm in JSW. Definitely I think that this is *not* 
> worth for this single case :) I'm just asking for some trick which meybe 
> is implemented already ;)
>
> Regards, Marcin

Re: [Wrapper-user] JVM appears hung: VMware, verbose garbage collection

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

Nathan,
Java does indeed appear frozen if its memory gets swapped to disk
or during long GC cycles.    To an outside process, the JVM is indeed
frozen while either event happens.

Looking at the wrapper.conf that you posted, you have your
wrapper.ping.timeout set to 10 seconds.  Why did you set it to a
value shorter than the default of 30 seconds?  My first suggestion
would be to set the timeout to 60 or 120 seconds and see how that
works for you.

An old version of the Wrapper started to shutdown cleanly when
a ping timeout was encountered.  But if the JVM is really frozen,
the shutdown would of course still fail.   If the JVM was not really
frozen then the JVM would still either be shutdown or killed.  If
the "frozen" state is an artifact of GC or of memory swapping, then
a better solution is to increase the ping timeout.

I have used the Wrapper under VMWare quite a bit.  But not in
cases where the JVM or VM were under heavy loads.  I have seen
problems when the host OS is under heavy loads, but that is not
surprising as VMWare becomes pretty doggish under those
circumstances.

One thing that greatly improved the VMWare performance in cases
where the host OS was under load was to disable VMWare from
allowing the VM's memory to be swapped.  Force it to stay in active
memory.  That gets rid of the long freezes.

Cheers,
Leif

Nathan Wray wrote:
>
> Hi;
>
> I have an application being deployed onto JBoss on Windows under 
> VMware.  JBoss is running as a service under wrapper.
> Although the application has run elsewhere for long periods of time 
> with no issues, we're seeing a problem under wrapper.
> Once the app has been running for 1-2 hours, we see:
>
> ERROR  | wrapper  | 2007/10/26 16:25:17 | JVM appears hung: Timed out 
> waiting for signal from JVM.
> ERROR  | wrapper  | 2007/10/26 16:25:18 | JVM did not exit on request, 
> terminated
>
> Our app is deployed as an EAR file, and if the JBoss server process 
> doesn't shut down cleanly it won't come back up without deleting the 
> tmp, work and data folders.  So once wrapper has gunned the server 
> it's dead until someone manually intervenes.
>
> Using the default ticks timer we see messages like this periodically:
>
>  The timer fell behind the system clock by 14600ms.
>
> Our server is a VMware instance, so it is possible that the VM could 
> be getting swapped out or starved.  This would probably appear to an 
> application as though the clock and timers were jumping out of sync in 
> ways that normally are impossible.
> Is anyone successfully using wrapper under VMware?
>
> Also we're running with verbose garbage collection, which I understand 
> can hang the server momentarily.  Are there known issues with verbose 
> garbage collection under wrapper?
>
> Looking through the code it doesn't appear that wrapper tries to shut 
> down the server once it decides there is a hang; it looks like it goes 
> right into WRAPPER_JSTATE_KILLING rather than WRAPPER_JSTATE_STOPPING; 
> so that the shutdownTimeout parameter does not come into play.  Would 
> it be possible to attempt a clean shutdown before killing the server?
>
>
> Selected settings below.  Note right now we're trying to address the 
> hard kill that leaves the server unusable, we will eventually bump up 
> the ping timeout to try and avoid the kill in the first place.
>
> # Number of seconds between Wrapper ping requests to the JVM.
> wrapper.ping.interval=5
>
> #Number of seconds to allow between the wrapper pinging the JVM and 
> the response.
> wrapper.ping.timeout=10
>
> #Number of seconds between JVM reports stopped and the JVM actually 
> terminates.
> wrapper.jvm_exit.timeout=60
> wrapper.shutdown.timeout=60
> wrapper.restart.delay=60
>
> wrapper.timer_fast_threshold=0
> wrapper.timer_slow_threshold=10
>
> # Force reload of wrapper config on JVM restart
> wrapper.restart.reload_configuration=TRUE
>
> Thanks for any insight you can bring.
>
> Nathan

[Wrapper-user] JVM appears hung: VMware, verbose garbage collection

[Nathan W. <wr...@de...>]

Hi;

I have an application being deployed onto JBoss on Windows under VMware.
JBoss is running as a service under wrapper.
Although the application has run elsewhere for long periods of time with no
issues, we're seeing a problem under wrapper.
Once the app has been running for 1-2 hours, we see:

ERROR  | wrapper  | 2007/10/26 16:25:17 | JVM appears hung: Timed out
waiting for signal from JVM.
ERROR  | wrapper  | 2007/10/26 16:25:18 | JVM did not exit on request,
terminated

Our app is deployed as an EAR file, and if the JBoss server process doesn't
shut down cleanly it won't come back up without deleting the tmp, work and
data folders.  So once wrapper has gunned the server it's dead until someone
manually intervenes.

Using the default ticks timer we see messages like this periodically:

 The timer fell behind the system clock by 14600ms.

Our server is a VMware instance, so it is possible that the VM could be
getting swapped out or starved.  This would probably appear to an
application as though the clock and timers were jumping out of sync in ways
that normally are impossible.
Is anyone successfully using wrapper under VMware?

Also we're running with verbose garbage collection, which I understand can
hang the server momentarily.  Are there known issues with verbose garbage
collection under wrapper?

Looking through the code it doesn't appear that wrapper tries to shut down
the server once it decides there is a hang; it looks like it goes right into
WRAPPER_JSTATE_KILLING rather than WRAPPER_JSTATE_STOPPING; so that the
shutdownTimeout parameter does not come into play.  Would it be possible to
attempt a clean shutdown before killing the server?


Selected settings below.  Note right now we're trying to address the hard
kill that leaves the server unusable, we will eventually bump up the ping
timeout to try and avoid the kill in the first place.

# Number of seconds between Wrapper ping requests to the JVM.
wrapper.ping.interval=5

#Number of seconds to allow between the wrapper pinging the JVM and the
response.
wrapper.ping.timeout=10

#Number of seconds between JVM reports stopped and the JVM actually
terminates.
wrapper.jvm_exit.timeout=60
wrapper.shutdown.timeout=60
wrapper.restart.delay=60

wrapper.timer_fast_threshold=0
wrapper.timer_slow_threshold=10

# Force reload of wrapper config on JVM restart
wrapper.restart.reload_configuration=TRUE

Thanks for any insight you can bring.

Nathan

-- 
Nathan Wray

Re: [Wrapper-user] Second integration method question

[Marcin W. <mwa...@su...>]

Hubert,

This in not related to my issue, but thanks for your response :) Meybe 
it will help me in the future.

Regards,
Marcin

Hubert Felber wrote:
> Hi,
> 
> IllegalStateException while stopping Wrapper? Sounds familiar somehow.
> 
> Maybe it has something to do with this?
> http://sourceforge.net/tracker/index.php?func=detail&aid=1799489&group_id=39428&atid=425187
> 
> The solution worked for me. No more IllegalStateException on shutdown.
> hub
> 

[Wrapper-user] Command arguments in Unix ps command

[Wayne J. <wjo...@mq...>]

Some of our users have complained that since we started using the Java =
Wrapper, that they can't find the process with the ps command.  Well, =
actually they can, just that it comes out something like:
=20
wjohnson 16248     1 09:27       00:18   3632  0.0 00:00:00    2 =
/home/wjohnson/qpasa/./wrapper /home/wjohnson/qpasa/qpws.conf =
wrapper.syslog.ident=3Dqpws =
wrapper.pidfile=3D/home/wjohnson/qpasa/./qpws.pid =
wrapper.daemonize=3DTRUE

Theoretically, on Unix, a program can overwrite it's command arguments =
with another string (see =
http://www.netsplit.com/blog/articles/2007/01/10/hiding-arguments-from-ps=
).  A common example of this is the infamous sendmail daemon.
=20
Some questions:
1) Is there already a way to do this with the wrapper?
2) Is it advisable to do this with the wrapper?  Is it safe?  Portable?
3) Is it something that would be useful in the community if I should =
come up with a patch?
4) Would the maintainers be willing to integrate such a patch?
=20
I have no problems writing the patch, but would prefer it become part of =
the product, rather than as a local change of course.
=20
Thanks.

Wayne Johnson=20
Senior Software Engineer=20
MQSoftware, Inc.=20
1660 S Highway 100=20
Minneapolis, MN 55416=20
(952) 345-8628=20

=20

Re: [Wrapper-user] Second integration method question

[Marcin W. <mwa...@su...>]

Leif Mortenson wrote:
> Marcin,
> Without using the wrapper, many applications launch a second JVM
> instance simply to trigger the shutdown of the first.  This is usually
> done by deleting an anchor file or sending a command via a socket.
> The wrapper makes this much lighter by running this shutdown
> code in the same JVM.

Yes, and this is OK! :)

> 
> Are you having problems running the shudown class in the same
> JVM? 

Yes, in case of Geronimo it result with IllegalStateException.

In "start" class we have execution of:
     KernelRegistry.registerKernel("MainBootstrapper");
and in "stop" class we have execution of the same:
     KernelRegistry.registerKernel("MainBootstrapper");
which in "stop" class result with
     java.lang.IllegalStateException: A kernel is already running this 
kernel

You can see discusion about it here:
http://www.mail-archive.com/us...@ge.../msg07665.html
Result of discussion is that it is *intended* to run shutdown class in a 
different vm. It means that second integration method can not be used 
(only first can be used) for Geronimo.

Of course the best solution is to modify Geronimo shutdown class. But 
first I decided to ask You if it is posible to do some trick to make it 
works in second integration method ;)

I'm *not* trying to tell you that it's worth to implement calling "stop" 
class in different vm in JSW. Definitely I think that this is *not* 
worth for this single case :) I'm just asking for some trick which meybe 
is implemented already ;)

Regards, Marcin

Re: [Wrapper-user] Second integration method question

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

Marcin,
Without using the wrapper, many applications launch a second JVM
instance simply to trigger the shutdown of the first.  This is usually
done by deleting an anchor file or sending a command via a socket.
The wrapper makes this much lighter by running this shutdown
code in the same JVM.

Are you having problems running the shudown class in the same
JVM? Or just assuming that it will not work.  Shutdown classes
tend to be quite simple in most cases.

Cheers,
Leif

Marcin Waldowski wrote:
> Hello.
>
> My problem is related to itegrate Apache Geronimo 2.0.1 and JWS via 
> second integration method.
>
> The same problem was touched is following thread 
> http://www.mail-archive.com/us...@ge.../msg07665.html
>
> Calling "stop" class within the same JVM as calling *start* class 
> results with error in Geronimo. As David Jencks wrote it's intended to 
> run shutdown.jar (from JWS point of view - "stop" class) in a different vm.
>
> The workaround is to use first integration method. However it need to 
> increase wrapper.jvm_exit.timeout because Geronimo shutdown hook may 
> need some more time to complete (the time depend on what is deployed on 
> Geronimo). So it could be better to stay with second integration method.
>
> Do you have some idea what to do to use second integration in such 
> situations?
>
> Regards, Marcin
>
> Leif Mortenson wrote:
>   
>> Marcin,
>> Not currently.  The Wrapper is only capable of monitoring a single JVM at
>> the moment.   In addition to be very heavy, controlling the lifecycle and
>> all of the possible failure modes for a second JVM would get complicated
>> in a hurry.
>>
>> What is the problem you are encountering that is requiring this?
>> I may have some ideas for you.
>>
>> Cheers,
>> Leif
>>
>> Marcin Waldowski wrote:
>>     
>>> One correction:
>>>
>>> Should be: I have noticed that calling "stop" class is done within the 
>>> same JVM as calling *start* class.
>>>
>>> Marcin Waldowski wrote:
>>>   
>>>       
>>>> Hello.
>>>>
>>>> In documentation we can read:
>>>> "The Wrapper works with this kind of application by starting up the 
>>>> application, as in the first method, using the "start" class and then 
>>>> calling the main method of the "stop" class when it is time for the 
>>>> application to be shutdown.".
>>>>
>>>> I have noticed that calling "stop" class is done within the same JVM 
>>>> as calling "stop" class. Is it possible to configure wrapper to call 
>>>> "stop" class in another JVM?
>>>>
>>>> Regards, Marcin
>>>>     

Re: [Wrapper-user] Second integration method question

[Hubert F. <Hub...@ab...>]

Hi,

IllegalStateException while stopping Wrapper? Sounds familiar somehow.

Maybe it has something to do with this?
http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1799489&group_=
id=3D39428&atid=3D425187

The solution worked for me. No more IllegalStateException on shutdown.
hub

>>> Marcin Waldowski <mwa...@su...> 22.10.2007 09:58 >>>
Hello.

My problem is related to itegrate Apache Geronimo 2.0.1 and JWS via=20
second integration method.

The same problem was touched is following thread=20
http://www.mail-archive.com/us...@ge.../msg07665.html=20

Calling "stop" class within the same JVM as calling *start* class=20
results with error in Geronimo. As David Jencks wrote it's intended to=20
run shutdown.jar (from JWS point of view - "stop" class) in a different =
vm.

The workaround is to use first integration method. However it need to=20
increase wrapper.jvm_exit.timeout because Geronimo shutdown hook may=20
need some more time to complete (the time depend on what is deployed on=20
Geronimo). So it could be better to stay with second integration method.

Do you have some idea what to do to use second integration in such=20
situations?

Regards, Marcin

Leif Mortenson wrote:
> Marcin,
> Not currently.  The Wrapper is only capable of monitoring a single JVM =
at
> the moment.   In addition to be very heavy, controlling the lifecycle =
and
> all of the possible failure modes for a second JVM would get complicated
> in a hurry.
>=20
> What is the problem you are encountering that is requiring this?
> I may have some ideas for you.
>=20
> Cheers,
> Leif
>=20
> Marcin Waldowski wrote:
>> One correction:
>>
>> Should be: I have noticed that calling "stop" class is done within =
the=20
>> same JVM as calling *start* class.
>>
>> Marcin Waldowski wrote:
>>  =20
>>> Hello.
>>>
>>> In documentation we can read:
>>> "The Wrapper works with this kind of application by starting up the=20
>>> application, as in the first method, using the "start" class and =
then=20
>>> calling the main method of the "stop" class when it is time for the=20
>>> application to be shutdown.".
>>>
>>> I have noticed that calling "stop" class is done within the same =
JVM=20
>>> as calling "stop" class. Is it possible to configure wrapper to =
call=20
>>> "stop" class in another JVM?
>>>
>>> Regards, Marcin
>>>    =20
>=20
>=20
> -------------------------------------------------------------------------=

> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/=20
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...=20
> https://lists.sourceforge.net/lists/listinfo/wrapper-user=20
>=20
>=20


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/=20
_______________________________________________
Wrapper-user mailing list
Wra...@li...=20
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] Second integration method question

[Marcin W. <mwa...@su...>]

Hello.

My problem is related to itegrate Apache Geronimo 2.0.1 and JWS via 
second integration method.

The same problem was touched is following thread 
http://www.mail-archive.com/us...@ge.../msg07665.html

Calling "stop" class within the same JVM as calling *start* class 
results with error in Geronimo. As David Jencks wrote it's intended to 
run shutdown.jar (from JWS point of view - "stop" class) in a different vm.

The workaround is to use first integration method. However it need to 
increase wrapper.jvm_exit.timeout because Geronimo shutdown hook may 
need some more time to complete (the time depend on what is deployed on 
Geronimo). So it could be better to stay with second integration method.

Do you have some idea what to do to use second integration in such 
situations?

Regards, Marcin

Leif Mortenson wrote:
> Marcin,
> Not currently.  The Wrapper is only capable of monitoring a single JVM at
> the moment.   In addition to be very heavy, controlling the lifecycle and
> all of the possible failure modes for a second JVM would get complicated
> in a hurry.
> 
> What is the problem you are encountering that is requiring this?
> I may have some ideas for you.
> 
> Cheers,
> Leif
> 
> Marcin Waldowski wrote:
>> One correction:
>>
>> Should be: I have noticed that calling "stop" class is done within the 
>> same JVM as calling *start* class.
>>
>> Marcin Waldowski wrote:
>>   
>>> Hello.
>>>
>>> In documentation we can read:
>>> "The Wrapper works with this kind of application by starting up the 
>>> application, as in the first method, using the "start" class and then 
>>> calling the main method of the "stop" class when it is time for the 
>>> application to be shutdown.".
>>>
>>> I have noticed that calling "stop" class is done within the same JVM 
>>> as calling "stop" class. Is it possible to configure wrapper to call 
>>> "stop" class in another JVM?
>>>
>>> Regards, Marcin
>>>     
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
> 
>