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

Re: [Wrapper-user] Install Wrapper as daemon in Linux

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

Yuval,
What exactly did you set up?

Assuming that you have an application installed at /usr/lib/myapp and a 
script
at /usr/lib/myapp/bin/myapp.sh.   You should have created a symbolic 
link in your
/etc/init.d directory as follows:
Make sure you are root, then execute
ln -s /etc/init.d/myapp /usr/lib/myapp/bin/myapp.sh

Test this script by running the following:
/etc/init.d/myapp
You should see a message telling you that the script requires a command.

Next, create the following links to setup your application to start and stop
correctly with the various system run levels:

ln -s /etc/rc0.d/K20myapp /etc/init.d/myapp
ln -s /etc/rc1.d/K20myapp /etc/init.d/myapp
ln -s /etc/rc6.d/K20myapp /etc/init.d/myapp
ln -s /etc/rc2.d/S20myapp /etc/init.d/myapp
ln -s /etc/rc3.d/S20myapp /etc/init.d/myapp
ln -s /etc/rc4.d/S20myapp /etc/init.d/myapp
ln -s /etc/rc5.d/S20myapp /etc/init.d/myapp

Once again, test the links by running the following:
/etc/init.d/myapp

If this does not work then it will not work when you reboot your system.
At this point we have verified that the links are all setup correctly 
and the
script should be run at the appropriate time.

If it does not work after rebooting then try enabling debug output in the
wrapper.conf file with wrapper.debug=true and then see if you get any
output in the wrapper.log file.

Cheers,
Leif


Yuval Zantkeren wrote:

>Hi,
>
>I'm trying to install the wrapper as daemon in Red Hat 9 Linux but with no
>luck.
>I don't have the command update-rc and also the chkconfig do not work with
>the wrapper.
>So I tried to make symbolic links from the script to /etc/init.d and than a
>symbolic links to the
>startup levels, but when the system go up and I see the services that starts
>I see the name of the service I installed but with no status,
>all the services that succeed show ok but the wrapper one do not show
>nothing (blank).
>
>Please Advise,
>
>Regards,
>
>Yuval
>  
>

Re: [Wrapper-user] Wrapper directories

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

Leif,

attached you will find the diff (I named my modified version 3.0.6).

Cheers,
Andreas

> -----Original Message-----
> From: Leif Mortenson [mailto:le...@ta...]
> Sent: Monday, March 15, 2004 3:56 PM
> To: wra...@li...
> Subject: Re: [Wrapper-user] Wrapper directories
> 
> 
> Andreas,
>     Go ahead and send me the diff and I'll take a look at it.
> 
> Thanks as always,
> Leif
> 
> Andreas Wendt wrote:
> 
> >Leif,
> >
> >thanks for the reply.
> >I did a quick hack on the 3.0.5 version via an environment 
> variable WRAPPER_HOME (name might not be perfect) on Windows 
> since I didn't want to change too much of the original code.
> >If you are interested in a diff, please let me know.
> >But I would agree to the comments for the feature request, 
> that a property inside the wrapper.conf would be better than 
> my solution.
> >
> >Cheers,
> >Andreas 
> >
> >  
> >
> >>-----Original Message-----
> >>From: Leif Mortenson [mailto:le...@ta...]
> >>Sent: Sunday, March 14, 2004 3:37 PM
> >>To: wra...@li...
> >>Subject: Re: [Wrapper-user] Wrapper directories
> >>
> >>
> >>Andreas,
> >>    Thanks for the reminder <:-)  I need to get around to 
> >>implementing 
> >>this.  The
> >>feature request was logged way too long ago.   No it is not 
> possible 
> >>with the
> >>current Wrapper.
> >>
> >>https://sourceforge.net/tracker/index.php?func=detail&aid=7381
> >>    
> >>
> >60&group_id=39428&atid=425190
> >
> >Cheers,
> >Leif
> >
> >Andreas Wendt wrote:
> >
> >  
> >
> >>Leif,
> >>
> >>is there a chance (in the current version 3.0.5 or in a 
> future one) to 
> >>specifiy the starting directory for the wrapper from 
> "outside" (e.g. 
> >>via an environment variable).
> >>
> >>I want to integrate with JBoss, but I don't want to copy 
> the wrapper 
> >>files to the jboss directories. Since the wrapper isn't able to use 
> >>another starting directory other than the executable's (Windows) or 
> >>the starting script's one (Unix), JBoss will not be able to start 
> >>properly due to some relative paths when constructing its classpath 
> >>from its config files.
> >>
> >>TIA,
> >>Andreas
> >>    
> >>
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
> 

[Wrapper-user] Install Wrapper as daemon in Linux

[Yuval Z. <yu...@do...>]

Hi,

I'm trying to install the wrapper as daemon in Red Hat 9 Linux but with n=
o
luck.
I don't have the command update-rc and also the chkconfig do not work wit=
h
the wrapper.
So I tried to make symbolic links from the script to /etc/init.d and than=
 a
symbolic links to the
startup levels, but when the system go up and I see the services that sta=
rts
I see the name of the service I installed but with no status,
all the services that succeed show ok but the wrapper one do not show
nothing (blank).

Please Advise,

Regards,

Yuval

=93This email message and any attachments hereto are intended only for us=
e by
the addressee(s) named above, and may contain legally privileged and/or
confidential information. If you are not the intended addressee, you are
hereby kindly notified that any dissemination, distribution or copying of
this email and any attachments hereto is strictly prohibited. If you have
received this email in error, kindly delete it from your computer system,
and notify us at the telephone number or email address appearing above.
Thank you"

Re: [Wrapper-user] more on problems with filters- restart never works

[Jennifer K. <jk...@si...>]

I am seeing out of memory exceptions well after startup.. again-- 
something I never saw w/o my process being under the wrapper..
I have yet to run the wrapped system under a profiler to look at what 
is going on more closely.

I could allocate more memory, (I have a max of 96m) per process.. but 
since i am running up to 30 processes I don't want to give each too 
much...
and again, this was never an issue before...

I am still getting OutOfMemory exceptions, but they are now allowing 
restarts..

Jennifer


On Mar 14, 2004, at 9:06 AM, Leif Mortenson wrote:

> Jennifer,
>    Does this solve the problems you were having with OutOfMemory 
> messages as
> well?  Were those all happening on startup?
>
> Cheers,
> Leif
>
> Jennifer Kolar wrote:
>
>> That did it. I didn't remember the Stop in the wrappersimpleapp...
>> Cool.
>> perfect.
>> Thanks
>>
>> On Mar 9, 2004, at 4:37 PM, Leif Mortenson wrote:
>>
>>> Jennifer,
>>>    I have been looking into this some more.  I added some more debug 
>>>  output to the
>>> WrapperManager class to make it easier to debug this sort of 
>>> problem.   You can try
>>> it from CVS if you like.  (SourceForge's public CVS is 24 hrs behind 
>>>  the dev archive)
>>>
>>>    Looking over the debug log output that you sent me again, I 
>>> noticed  the following
>>> line:
>>>
>>> INFO   | jvm 7    | 2004/02/26 19:33:00 | Thread,  
>>> WrapperSimpleAppMain, handling the shutdown process.
>>>
>>>    This tells me that the WrapperSimpleApp helper class's main 
>>> thread  called
>>> WrapperManager.stop.  This will happen if your class's main method  
>>> throws an
>>> uncaught exception.  Does that sound what might be happening?
>>>
>>>    If this is the case then I would expect to have seen the 
>>> following  output in your log.
>>> The log you posted was edited so you may have removed it.  Could you 
>>>  please confirm
>>> one way or the other?
>>>
>>> INFO   | jvm 7    | 2004/02/26 19:32:59 | WrapperSimpleApp:  
>>> Encountered an error running main: (Your exception)
>>>
>>>    If you are trying to invoke a restart on the above exception, it  
>>> will not work because
>>> the call to WrapperManager.stop will override the restart request 
>>> and  stop the Wrapper
>>> along with its JVM.
>>>
>>> Cheers,
>>> Leif
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] Feature request- use commons-logging

[Jennifer K. <jk...@si...>]

Leif,
see below.
On Mar 14, 2004, at 9:04 AM, Leif Mortenson wrote:

> Jennifer,
>    It is currently possible to send log messages to the Wrapper at any 
> log level my
> using the WrapperManager.log(level, message) method.  This sends the 
> messages
> across the socket so it is not appropriate for high volumes of 
> messages.  It works
> great for the occasional event log message however.
>
my problem is that there are many underlaying files and their various 
logging in place-- all using commons logging or some similiar
general function-- so it isn't practical to add the wrappermanager.log 
command everywhere. I can add it here and there-- but also, many 
portions of my code have no knowledge of the wrapper, and no 
dependencies, and I want to keep it that way. I will look into making 
my own logger implementation for commons-logging that will call this 
wrappermanager.log method and see how that goes..

>    I have been looking at ways of making it efficient to send messages 
> at various
> log levels off through the stderr/stdout streams.  It involves 
> intercepting all console
> output (possible) and then modifying each line so it starts with a log 
> level code.
> The Wrapper process would then parse these codes to decide what level 
> at which
> to log the messages.  It should be pretty light weight as well..   
> Still needs to put to
> code though.  There are a few gotchas with this that I am still trying 
> to work out in
> my head however.

that would work-- any sense on when you are planning on implementing 
this?
>
>    As for using commons logging.  I am strongly against that.  Not 
> that there is
> anything wrong with it.  But I want to maintain the 0 dependency 
> nature of the
> Java Service Wrapper.  That is one of the things that makes it so 
> useful.
> Personally I use the Apache Avalon LogKit logger for a number of 
> reasons.
> Everyone has their own personal preference.
>
That's fine.. I understand. it is less of a concern to me what you use 
internally for logging than the fact that I can't use
typically logging infrastructures like commons logging..

>    Once I get the ability to log console output at different log 
> levels working.  The
> next logical step would be to provide a method for Commons logging, 
> logkit etc
> to hook into the Wrapper logging system and use it as a log target, 
> rather than
> the other way around.
>

makes sense..

Thanks
Jennifer
>    Let me know if you have any suggestions.
>
> Cheers,
> Leif
>
> Jennifer Kolar wrote:
>
>> My request is to either use commons-logging throughout your app-- 
>> since you have essentially created your own implementation of it--
>> and allow through the inner spawned applications commons-logging 
>> messages at their relative levels (rather than only wrapping them all 
>> in info)..
>>
>> or leave your implementation as is, but still allow through the 
>> spawned applications commons-logging messages at their levels rather 
>> than putting everything in info.
>>
>> Where this is a real problem for me is the event logging. I can't 
>> send any of my application errors to the event log - using your code 
>> as is- unless I enable info .. which is way more verbose than I want 
>> to send to the log..
>>
>> not sure if you have thought about doing this already or not, I know 
>> you recently reworked how you pass through stdout..
>> If you have thought about it-- what implementation plan did you have 
>> that I could perhaps follow early?
>>
>> I know you capture all std out from the calling app-- so maybe you 
>> would have to filter each message looking for commons logging
>> levels and map those to the appropriate level in your app.. if you 
>> didn't think it reasonable to just use commons-logging wholesale. 
>> Just one thought...
>>
>> thanks
>> Jennifer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] Wrapper directories

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

Andreas,
    Go ahead and send me the diff and I'll take a look at it.

Thanks as always,
Leif

Andreas Wendt wrote:

>Leif,
>
>thanks for the reply.
>I did a quick hack on the 3.0.5 version via an environment variable WRAPPER_HOME (name might not be perfect) on Windows since I didn't want to change too much of the original code.
>If you are interested in a diff, please let me know.
>But I would agree to the comments for the feature request, that a property inside the wrapper.conf would be better than my solution.
>
>Cheers,
>Andreas 
>
>  
>
>>-----Original Message-----
>>From: Leif Mortenson [mailto:le...@ta...]
>>Sent: Sunday, March 14, 2004 3:37 PM
>>To: wra...@li...
>>Subject: Re: [Wrapper-user] Wrapper directories
>>
>>
>>Andreas,
>>    Thanks for the reminder <:-)  I need to get around to 
>>implementing 
>>this.  The
>>feature request was logged way too long ago.   No it is not possible 
>>with the
>>current Wrapper.
>>
>>https://sourceforge.net/tracker/index.php?func=detail&aid=7381
>>    
>>
>60&group_id=39428&atid=425190
>
>Cheers,
>Leif
>
>Andreas Wendt wrote:
>
>  
>
>>Leif,
>>
>>is there a chance (in the current version 3.0.5 or in a future one) to 
>>specifiy the starting directory for the wrapper from "outside" (e.g. 
>>via an environment variable).
>>
>>I want to integrate with JBoss, but I don't want to copy the wrapper 
>>files to the jboss directories. Since the wrapper isn't able to use 
>>another starting directory other than the executable's (Windows) or 
>>the starting script's one (Unix), JBoss will not be able to start 
>>properly due to some relative paths when constructing its classpath 
>>from its config files.
>>
>>TIA,
>>Andreas
>>    
>>

Re: [Wrapper-user] wrapperKillProcess()

[Richard E. <rem...@ed...>]

Leif,

You are correct, if the JVM is really hung, then sending it a SIGTERM
will do no good.

I have a process that the wrapper manages and that process has a 
subprocess. The process has a shutdown hook which will kill the
subprocess when the process receives a SIGTERM; the process's
shutdown hooks are not invoked when it receives a SIGKILL. ...
nothing new here. What I've now done is when the wrapper
launches the process, if it detects that there is a subprocess
running (from a previous run), it will tell the old subprocess to
die before it creates its new subprocess.

For my situation this works because I have only one, well known
subprocess with a well known communication port.

Thanks,

Richard

RE: [Wrapper-user] Wrapper directories

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

Leif,

thanks for the reply.
I did a quick hack on the 3.0.5 version via an environment variable WRAPPER_HOME (name might not be perfect) on Windows since I didn't want to change too much of the original code.
If you are interested in a diff, please let me know.
But I would agree to the comments for the feature request, that a property inside the wrapper.conf would be better than my solution.

Cheers,
Andreas 

> -----Original Message-----
> From: Leif Mortenson [mailto:le...@ta...]
> Sent: Sunday, March 14, 2004 3:37 PM
> To: wra...@li...
> Subject: Re: [Wrapper-user] Wrapper directories
> 
> 
> Andreas,
>     Thanks for the reminder <:-)  I need to get around to 
> implementing 
> this.  The
> feature request was logged way too long ago.   No it is not possible 
> with the
> current Wrapper.
> 
> https://sourceforge.net/tracker/index.php?func=detail&aid=7381
60&group_id=39428&atid=425190

Cheers,
Leif

Andreas Wendt wrote:

> Leif,
>
> is there a chance (in the current version 3.0.5 or in a future one) to 
> specifiy the starting directory for the wrapper from "outside" (e.g. 
> via an environment variable).
>
> I want to integrate with JBoss, but I don't want to copy the wrapper 
> files to the jboss directories. Since the wrapper isn't able to use 
> another starting directory other than the executable's (Windows) or 
> the starting script's one (Unix), JBoss will not be able to start 
> properly due to some relative paths when constructing its classpath 
> from its config files.
>
> TIA,
> Andreas
>



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] disabling automatic shutdowns

[Shmulik R. <sh...@vs...>]

On 15 Mar 2004 at 2:16, Leif Mortenson wrote:

>     I was able to reproduce this using those timeout values.  It is
>     late 
> here, so it is not
> immediately obvious what the problem is.  I will take a look at it. 

thanks.

> But for now please go back and remove the three timeout / interval
> properties below.  What was the original reason that you had wanted to
> set them?   Setting the timeout to 0 works. But the long ping interval
> seems to be causing problems right now...
We originally started messing with these properties after we noticed 
the jvm is restarted by the wrapper. this is probably due to a bug in 
our application (that causes extensive cpU usage) which is hard to 
debug when the wrapper restarts the application below our feet.

Cheers,
Shmul 

Re: [Wrapper-user] disabling automatic shutdowns

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

Shmulik,
    I was able to reproduce this using those timeout values.  It is late 
here, so it is not
immediately obvious what the problem is.  I will take a look at it.  But 
for now please
go back and remove the three timeout / interval properties below.  What 
was the
original reason that you had wanted to set them?   Setting the timeout 
to 0 works.
But the long ping interval seems to be causing problems right now...

Cheers,
Leif

Shmulik Regev wrote:

>I followed your advise, but for some reason things got worse (or 
>maybe better, it'll be easier to debug now :) and the process 
>terminates almost immediately. 
>
>The configuration is:
>wrapper.cpu.timeout=0
>wrapper.ping.interval=3600
>wrapper.ping.timeout=0
>
>
>and the log (there are of course some application specific lines, but 
>these are easily recognized)
>
>INFO   | jvm 1    | 2004/03/14 19:07:25 | Write output to log file "c:\vself/logs/feed_jaco.log"
>INFO   | jvm 1    | 2004/03/14 19:07:25 | Write output to log file "c:\vself/logs/feed_jaco.log"
>INFO   | jvm 1    | 2004/03/14 19:07:25 | 	JacORB V 1.3.30, www.jacorb.org
>INFO   | jvm 1    | 2004/03/14 19:07:25 | 	(C) Gerald Brose, FU Berlin, 13 June 2001
>INFO   | jvm 1    | 2004/03/14 19:07:25 | Virtual Self Feed Broker 2.6.2 (186)
>DEBUG  | wrapper  | 2004/03/14 19:07:25 | Pause reading child output to share cycles.
>INFO   | jvm 1    | 2004/03/14 19:07:25 | Active...
>INFO   | jvm 1    | 2004/03/14 19:07:25 | WrapperSimpleApp: start(args) end.  Main Completed=false, exitCode=null
>INFO   | jvm 1    | 2004/03/14 19:07:25 | returned from listener.start()
>INFO   | jvm 1    | 2004/03/14 19:07:25 | Send a packet STARTED : 
>DEBUG  | wrapperp | 2004/03/14 19:07:25 | read a packet STARTED : 
>DEBUG  | wrapper  | 2004/03/14 19:07:25 | JVM signalled that it was started.
>INFO   | jvm 1    | 2004/03/14 19:07:35 | Read Timed out. (Last Ping was 10016 milliseconds ago)
>INFO   | jvm 1    | 2004/03/14 19:07:39 | D_Lib: output is switched to file c:\vself/logs\/fn.0.log
>INFO   | jvm 1    | 2004/03/14 19:07:39 | Starting fn, see c:\vself/logs\/fn for logging...
>INFO   | jvm 1    | 2004/03/14 19:07:46 | Read Timed out. (Last Ping was 20016 milliseconds ago)
>INFO   | jvm 1    | 2004/03/14 19:07:55 | Read Timed out. (Last Ping was 30016 milliseconds ago)
>ERROR  | wrapper  | 2004/03/14 19:07:56 | JVM appears hung: Timed out waiting for signal from JVM.
>ERROR  | wrapper  | 2004/03/14 19:07:56 | Java Virtual Machine did not exit on request, terminated
>DEBUG  | wrapper  | 2004/03/14 19:07:56 | JVM was only running for 33 seconds leading to a failed restart count of 1.
>
>Cheers,
>Shmul
>  
>

Re: [Wrapper-user] disabling automatic shutdowns

[Shmulik R. <sh...@vs...>]

I followed your advise, but for some reason things got worse (or 
maybe better, it'll be easier to debug now :) and the process 
terminates almost immediately. 

The configuration is:
wrapper.cpu.timeout=0
wrapper.ping.interval=3600
wrapper.ping.timeout=0


and the log (there are of course some application specific lines, but 
these are easily recognized)

INFO   | jvm 1    | 2004/03/14 19:07:25 | Write output to log file "c:\vself/logs/feed_jaco.log"
INFO   | jvm 1    | 2004/03/14 19:07:25 | Write output to log file "c:\vself/logs/feed_jaco.log"
INFO   | jvm 1    | 2004/03/14 19:07:25 | 	JacORB V 1.3.30, www.jacorb.org
INFO   | jvm 1    | 2004/03/14 19:07:25 | 	(C) Gerald Brose, FU Berlin, 13 June 2001
INFO   | jvm 1    | 2004/03/14 19:07:25 | Virtual Self Feed Broker 2.6.2 (186)
DEBUG  | wrapper  | 2004/03/14 19:07:25 | Pause reading child output to share cycles.
INFO   | jvm 1    | 2004/03/14 19:07:25 | Active...
INFO   | jvm 1    | 2004/03/14 19:07:25 | WrapperSimpleApp: start(args) end.  Main Completed=false, exitCode=null
INFO   | jvm 1    | 2004/03/14 19:07:25 | returned from listener.start()
INFO   | jvm 1    | 2004/03/14 19:07:25 | Send a packet STARTED : 
DEBUG  | wrapperp | 2004/03/14 19:07:25 | read a packet STARTED : 
DEBUG  | wrapper  | 2004/03/14 19:07:25 | JVM signalled that it was started.
INFO   | jvm 1    | 2004/03/14 19:07:35 | Read Timed out. (Last Ping was 10016 milliseconds ago)
INFO   | jvm 1    | 2004/03/14 19:07:39 | D_Lib: output is switched to file c:\vself/logs\/fn.0.log
INFO   | jvm 1    | 2004/03/14 19:07:39 | Starting fn, see c:\vself/logs\/fn for logging...
INFO   | jvm 1    | 2004/03/14 19:07:46 | Read Timed out. (Last Ping was 20016 milliseconds ago)
INFO   | jvm 1    | 2004/03/14 19:07:55 | Read Timed out. (Last Ping was 30016 milliseconds ago)
ERROR  | wrapper  | 2004/03/14 19:07:56 | JVM appears hung: Timed out waiting for signal from JVM.
ERROR  | wrapper  | 2004/03/14 19:07:56 | Java Virtual Machine did not exit on request, terminated
DEBUG  | wrapper  | 2004/03/14 19:07:56 | JVM was only running for 33 seconds leading to a failed restart count of 1.





Cheers,
Shmul



> Shmul,
>     You are actually doing things correctly except for a minor detail.
>       
> The wrapper.conf
> file does not currently support having spaces around the '=' sign in
> the property names. The way the conf file is parsed, the Wrapper will
> not see such properties.   I have submitted the following bug and will
> get this fixed for a future version.
> https://sourceforge.net/tracker/index.php?func=detail&aid=916001&group
> _id=39428&atid=425187
> 
>     For now, please go through and remove the spaces from the property
>     
> definitions.
> You should then be able to disable the pings.
> 
>     Cheers,
>     Leif
> 
> Shmulik Regev wrote:
> 
> >I followed your advice and run the wrapper with debug information
> >switched on. Attached please find the log and the wrapper.conf file. 
> >
> >Please note that I'm not posting this file to the user group as I'm
> >not sure it is appropriate. However if you feel otherwise please tell
> > me. 
> >
> >I appreciate the help.
> >
> >
> >Cheers,
> >Shmul
> >  
> >

Re: [Wrapper-user] more on problems with filters- restart never works

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

Jennifer,
    Does this solve the problems you were having with OutOfMemory 
messages as
well?  Were those all happening on startup?

Cheers,
Leif

Jennifer Kolar wrote:

> That did it. I didn't remember the Stop in the wrappersimpleapp...
> Cool.
> perfect.
> Thanks
>
> On Mar 9, 2004, at 4:37 PM, Leif Mortenson wrote:
>
>> Jennifer,
>>    I have been looking into this some more.  I added some more debug  
>> output to the
>> WrapperManager class to make it easier to debug this sort of 
>> problem.   You can try
>> it from CVS if you like.  (SourceForge's public CVS is 24 hrs behind  
>> the dev archive)
>>
>>    Looking over the debug log output that you sent me again, I 
>> noticed  the following
>> line:
>>
>> INFO   | jvm 7    | 2004/02/26 19:33:00 | Thread,  
>> WrapperSimpleAppMain, handling the shutdown process.
>>
>>    This tells me that the WrapperSimpleApp helper class's main 
>> thread  called
>> WrapperManager.stop.  This will happen if your class's main method  
>> throws an
>> uncaught exception.  Does that sound what might be happening?
>>
>>    If this is the case then I would expect to have seen the 
>> following  output in your log.
>> The log you posted was edited so you may have removed it.  Could you  
>> please confirm
>> one way or the other?
>>
>> INFO   | jvm 7    | 2004/02/26 19:32:59 | WrapperSimpleApp:  
>> Encountered an error running main: (Your exception)
>>
>>    If you are trying to invoke a restart on the above exception, it  
>> will not work because
>> the call to WrapperManager.stop will override the restart request 
>> and  stop the Wrapper
>> along with its JVM.
>>
>> Cheers,
>> Leif
>

Re: [Wrapper-user] Feature request- use commons-logging

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

Jennifer,
    It is currently possible to send log messages to the Wrapper at any 
log level my
using the WrapperManager.log(level, message) method.  This sends the 
messages
across the socket so it is not appropriate for high volumes of 
messages.  It works
great for the occasional event log message however.

    I have been looking at ways of making it efficient to send messages 
at various
log levels off through the stderr/stdout streams.  It involves 
intercepting all console
output (possible) and then modifying each line so it starts with a log 
level code.
The Wrapper process would then parse these codes to decide what level at 
which
to log the messages.  It should be pretty light weight as well..   Still 
needs to put to
code though.  There are a few gotchas with this that I am still trying 
to work out in
my head however.

    As for using commons logging.  I am strongly against that.  Not that 
there is
anything wrong with it.  But I want to maintain the 0 dependency nature 
of the
Java Service Wrapper.  That is one of the things that makes it so useful.
Personally I use the Apache Avalon LogKit logger for a number of reasons.
Everyone has their own personal preference.

    Once I get the ability to log console output at different log levels 
working.  The
next logical step would be to provide a method for Commons logging, 
logkit etc
to hook into the Wrapper logging system and use it as a log target, 
rather than
the other way around.

    Let me know if you have any suggestions.

Cheers,
Leif

Jennifer Kolar wrote:

> My request is to either use commons-logging throughout your app-- 
> since you have essentially created your own implementation of it--
> and allow through the inner spawned applications commons-logging 
> messages at their relative levels (rather than only wrapping them all 
> in info)..
>
> or leave your implementation as is, but still allow through the 
> spawned applications commons-logging messages at their levels rather 
> than putting everything in info.
>
> Where this is a real problem for me is the event logging. I can't send 
> any of my application errors to the event log - using your code as is- 
> unless I enable info .. which is way more verbose than I want to send 
> to the log..
>
> not sure if you have thought about doing this already or not, I know 
> you recently reworked how you pass through stdout..
> If you have thought about it-- what implementation plan did you have 
> that I could perhaps follow early?
>
> I know you capture all std out from the calling app-- so maybe you 
> would have to filter each message looking for commons logging
> levels and map those to the appropriate level in your app.. if you 
> didn't think it reasonable to just use commons-logging wholesale. Just 
> one thought...
>
> thanks
> Jennifer

[Wrapper-user] Feature request- use commons-logging

[Jennifer K. <jk...@si...>]

My request is to either use commons-logging throughout your app-- since 
you have essentially created your own implementation of it--
and allow through the inner spawned applications commons-logging 
messages at their relative levels (rather than only wrapping them all 
in info)..

or leave your implementation as is, but still allow through the spawned 
applications commons-logging messages at their levels rather than 
putting everything in info.

Where this is a real problem for me is the event logging. I can't send 
any of my application errors to the event log - using your code as is- 
unless I enable info .. which is way more verbose than I want to send 
to the log..

not sure if you have thought about doing this already or not, I know 
you recently reworked how you pass through stdout..
If you have thought about it-- what implementation plan did you have 
that I could perhaps follow early?

I know you capture all std out from the calling app-- so maybe you 
would have to filter each message looking for commons logging
levels and map those to the appropriate level in your app.. if you 
didn't think it reasonable to just use commons-logging wholesale. Just 
one thought...

thanks
Jennifer

Re: [Wrapper-user] more on problems with filters- restart never works

[Jennifer K. <jk...@si...>]

That did it. I didn't remember the Stop in the wrappersimpleapp...
Cool.
perfect.
Thanks

On Mar 9, 2004, at 4:37 PM, Leif Mortenson wrote:

> Jennifer,
>    I have been looking into this some more.  I added some more debug  
> output to the
> WrapperManager class to make it easier to debug this sort of problem.   
> You can try
> it from CVS if you like.  (SourceForge's public CVS is 24 hrs behind  
> the dev archive)
>
>    Looking over the debug log output that you sent me again, I noticed  
> the following
> line:
>
> INFO   | jvm 7    | 2004/02/26 19:33:00 | Thread,  
> WrapperSimpleAppMain, handling the shutdown process.
>
>    This tells me that the WrapperSimpleApp helper class's main thread  
> called
> WrapperManager.stop.  This will happen if your class's main method  
> throws an
> uncaught exception.  Does that sound what might be happening?
>
>    If this is the case then I would expect to have seen the following  
> output in your log.
> The log you posted was edited so you may have removed it.  Could you  
> please confirm
> one way or the other?
>
> INFO   | jvm 7    | 2004/02/26 19:32:59 | WrapperSimpleApp:  
> Encountered an error running main: (Your exception)
>
>    If you are trying to invoke a restart on the above exception, it  
> will not work because
> the call to WrapperManager.stop will override the restart request and  
> stop the Wrapper
> along with its JVM.
>
> Cheers,
> Leif
>
> Jennifer Kolar wrote:
>
>> Leif,
>>
>> It appears that I never have a successful FILTER based restart.  I  
>> have no problem getting restarts when I call WrapperManager.restart()  
>> internally.. however--
>> if there is an exception that I didn't catch that a filter matches,  
>> then I never get a successful restart. I have had each of the  
>> following filters triggered always with the same result.
>>
>> I noticed that there was a recent email (Patrick Woodworth 1/23/2004)  
>>  where another person was having similiar problems and he found  
>> disabling the shutdown hooks to be a soln for him.. I've had that  
>> disabled this whole time and  don't see any difference.
>>
>>
>> Here are my filter settings from my conf file.
>>
>>      
>> wrapper.filter.trigger.1=com.singingfish.werkflow.processors.Processor 
>> Exception
>>     wrapper.filter.action.1=RESTART
>>
>>     wrapper.filter.trigger.2=java.lang.Error
>>     wrapper.filter.action.2=RESTART
>>
>>     wrapper.filter.trigger.3=java.lang.OutOfMemoryError
>>     wrapper.filter.action.3=RESTART
>>
>>
>> I also have these set if it provides any help..  ( I have tried  
>> playing around w/ different startup timeouts and invocation times and  
>> it seems to make no difference)
>>
>>     wrapper.jvm_exit.timeout=30
>>     wrapper.cpu.timeout=10
>>     wrapper.ping.timeout=300
>>     wrapper.ping.interval=5
>>     wrapper.restart.delay=1
>>     wrapper.max_failed_invocations=3
>>     wrapper.successful_invocation_time=10
>>     wrapper.startup.timeout=30
>>     wrapper.request_thread_dump_on_failed_jvm_exit=FALSE
>>     wrapper.ignore_signals=TRUE
>>     wrapper.disable_shutdown_hook=TRUE
>>
>> And again, here is the result I see whenever a filter is triggered:
>>
>>
>> *STATUS | wrapper  | 2004/02/26 19:32:59 | Filter trigger matched.   
>> Restarting JVM.*
>> *DEBUG  | wrapper  | 2004/02/26 19:32:59 | wrapperRestartProcess()  
>> called*
>> ... (stuff from my stacktrack)
>> *STATUS | wrapper  | 2004/02/26 19:32:59 | Filter trigger matched.   
>> Restarting JVM.*
>> *DEBUG  | wrapper  | 2004/02/26 19:32:59 | wrapperRestartProcess()  
>> called.  (IGNORED)*
>> INFO   | jvm 7    | 2004/02/26 19:32:59 | java.lang.Error:  
>> com.singingfish.werkflow.processors.ProcessorException: Unexpected  
>> exception in cracker
>> *STATUS | wrapper  | 2004/02/26 19:32:59 | Filter trigger matched.   
>> Restarting JVM.*
>> *DEBUG  | wrapper  | 2004/02/26 19:32:59 | wrapperRestartProcess()  
>> called.  (IGNORED)*
>> ... (stuff from my stack track)
>> INFO   | jvm 7    | 2004/02/26 19:32:59 | Send a packet STOP : 0
>> DEBUG  | wrapperp | 2004/02/26 19:32:59 | read a packet STOP : 0
>> DEBUG  | wrapper  | 2004/02/26 19:32:59 | JVM requested a shutdown.  
>> (0)
>> DEBUG  | wrapper  | 2004/02/26 19:32:59 | wrapperStopProcess(0)  
>> called.
>> DEBUG  | wrapper  | 2004/02/26 19:32:59 | Sending stop signal to JVM
>> DEBUG  | wrapperp | 2004/02/26 19:32:59 | send a packet STOP : NULL
>> INFO   | jvm 7    | 2004/02/26 19:32:59 | Received a packet STOP :
>> INFO   | jvm 7    | 2004/02/26 19:33:00 | Thread,  
>> WrapperSimpleAppMain, handling the shutdown process.
>> INFO   | jvm 7    | 2004/02/26 19:33:00 | calling listener.stop()
>> INFO   | jvm 7    | 2004/02/26 19:33:00 | WrapperSimpleApp: stop(0)
>> INFO   | jvm 7    | 2004/02/26 19:33:00 | returned from  
>> listener.stop()
>> INFO   | jvm 7    | 2004/02/26 19:33:00 | Send a packet STOPPED : 0
>> DEBUG  | wrapperp | 2004/02/26 19:33:00 | read a packet STOPPED : 0
>> DEBUG  | wrapper  | 2004/02/26 19:33:00 | JVM signalled that it was  
>> stopped.
>> INFO   | jvm 7    | 2004/02/26 19:33:00 | Closing socket.
>> DEBUG  | wrapperp | 2004/02/26 19:33:00 | socket read no code  
>> (closed?).
>> INFO   | jvm 7    | 2004/02/26 19:33:00 | calling System.exit(0)
>> INFO   | jvm 7    | 2004/02/26 19:33:00 | Server daemon shut down
>> DEBUG  | wrapper  | 2004/02/26 19:33:00 | JVM exited normally.
>> STATUS | wrapper  | 2004/02/26 19:33:01 | <-- Wrapper Stopped
>> STATUS | wrapper  | 2004/02/26 19:36:28 | CrackerAgent3 removed.
>>
>>
>> in comparison-- a normal restart has the following ...
>>
>>
>> INFO   | jvm 6    | 2004/02/26 19:31:48 | 2004-02-26 19:31:48,107  
>> DEBUG [WrapperSimpleAppMain] WerkflowAgent             -  
>> WerkflowEngine requested VM restart (null). Shutting down...
>> INFO   | jvm 6    | 2004/02/26 19:31:48 | Send a packet RESTART :  
>> restart
>> DEBUG  | wrapperp | 2004/02/26 19:31:48 | read a packet RESTART :  
>> restart
>> STATUS | wrapper  | 2004/02/26 19:31:48 | JVM requested a restart.
>> DEBUG  | wrapper  | 2004/02/26 19:31:48 | wrapperRestartProcess()  
>> called.
>> DEBUG  | wrapper  | 2004/02/26 19:31:48 | Sending stop signal to JVM
>> DEBUG  | wrapperp | 2004/02/26 19:31:48 | send a packet STOP : NULL
>> INFO   | jvm 6    | 2004/02/26 19:31:48 | Received a packet STOP :
>> INFO   | jvm 6    | 2004/02/26 19:31:49 | Thread,  
>> WrapperSimpleAppMain, handling the shutdown process.
>> INFO   | jvm 6    | 2004/02/26 19:31:49 | calling listener.stop()
>> INFO   | jvm 6    | 2004/02/26 19:31:49 | WrapperSimpleApp: stop(0)
>> INFO   | jvm 6    | 2004/02/26 19:31:49 | returned from  
>> listener.stop()
>> INFO   | jvm 6    | 2004/02/26 19:31:49 | Send a packet STOPPED : 0
>> DEBUG  | wrapperp | 2004/02/26 19:31:49 | read a packet STOPPED : 0
>> DEBUG  | wrapper  | 2004/02/26 19:31:49 | JVM signalled that it was  
>> stopped.
>> INFO   | jvm 6    | 2004/02/26 19:31:49 | Closing socket.
>> DEBUG  | wrapperp | 2004/02/26 19:31:49 | socket read no code  
>> (closed?).
>> INFO   | jvm 6    | 2004/02/26 19:31:50 | calling System.exit(0)
>> INFO   | jvm 6    | 2004/02/26 19:31:50 | Server daemon shut down
>> DEBUG  | wrapper  | 2004/02/26 19:31:50 | JVM exited normally.
>> STATUS | wrapper  | 2004/02/26 19:31:52 | Launching a JVM...
>> DEBUG  | wrapper  | 2004/02/26 19:31:52 | command:  
>> "C:\WINNT\system32\java.exe"  
>> -Dcom.singingfish.core.utils.config.dir=c:/sf/config  
>> -Duser.dir=C:\aolrun -Dsun.rmi.loader.logLevel=VERBOSE  
>> -Dsun.rmi.server.logLevel=VERBOSE  
>> -Dsun.rmi.transport.logLevel=VERBOSE  
>> -Dsun.rmi.transport.tcp.logLevel=VERBOSE  
>> -Dsun.rmi.transport.proxy.logLevel=VERBOSE -Xms3m -Xmx96m  
>> -Djava.library.path="c:/sf/lib;c:/winnt;c:/winnt/system32;c:/ 
>> j2sdk1.4.2_02/bin" -classpath  
>> "c:/sf/java/classes;c:/sf/java/jars/commons-logging-1.0.3/commons- 
>> logging.jar;c:/sf/java/jars/jakarta-log4j-1.2.8/dist/lib/log4j 
>> -1.2.8.jar;c:/sf/java/jars/jakarta-oro-2.0.4/jakarta-oro-2.0.4.jar;c: 
>> /sf/java/jars/quicktime_6_5/QTJava.zip;c:/sf/java/jars/xerces-1_3_1/ 
>> xerces.jar;c:/sf/java/jars/toplink/TOPLink.jar;c:/sf/java/jars/ 
>> toplink/Tools.jar;c:/sf/java/jars/toplink/TOPLinkX.jar;c:/sf/java/ 
>> jars/oracle_jdbc_9_2_03/ojdbc14.jar;c:/sf/java/jars/commons- 
>> httpclient-2.0/commons-httpclient-2.0-final.jar"  
>> -Dwrapper.key="VRxfE5Fd856GSIaF" -Dwrapper.port=32013  
>> -Dwrapper.debug="TRUE" -Dwrapper.ignore_signals="TRUE"  
>> -Dwrapper.service="TRUE" -Dwrapper.disable_shutdown_hook="TRUE"  
>> -Dwrapper.cpu.timeout="10" -Dwrapper.jvmid=7  
>> org.tanukisoftware.wrapper.WrapperSimpleApp  
>> com.singingfish.werkflow.agent.WerkflowAgent  
>> c:/sf/config/workflow/specs/cracker.spec CrackerAgent3
>> DEBUG  | wrapper  | 2004/02/26 19:31:52 | Java Virtual Machine  
>> started (PID=9244)
>> INFO   | jvm 7    | 2004/02/26 19:31:52 | Wrapper Manager: JVM #7
>> INFO   | jvm 7    | 2004/02/26 19:31:52 | Wrapper Manager: Using  
>> wrapper
>> INFO   | jvm 7    | 2004/02/26 19:31:52 | Calling native  
>> initialization method.
>> INFO   | jvm 7    | 2004/02/26 19:31:52 | Initializing WrapperManager  
>> native library.
>> INFO   | jvm 7    | 2004/02/26 19:31:52 | Java Executable:  
>> C:\WINNT\system32\java.exe
>> INFO   | jvm 7    | 2004/02/26 19:31:52 | Java Version   :  
>> 1.4.2_02-b03 Java HotSpot(TM) Client VM
>> INFO   | jvm 7    | 2004/02/26 19:31:52 | Java VM Vendor : Sun  
>> Microsystems Inc.
>> INFO   | jvm 7    | 2004/02/26 19:31:52 |
>> INFO   | jvm 7    | 2004/02/26 19:31:52 | Wrapper (Version 3.0.5)
>> INFO   | jvm 7    | 2004/02/26 19:31:52 |
>> INFO   | jvm 7    | 2004/02/26 19:31:52 | Open socket to wrapper  
>> attempted on port 32013...
>> INFO   | jvm 7    | 2004/02/26 19:31:52 | Opened Socket to port 3242
>> INFO   | jvm 7    | 2004/02/26 19:31:52 | Send a packet KEY :  
>> VRxfE5Fd856GSIaF
>> INFO   | jvm 7    | 2004/02/26 19:31:52 |  
>> handleSocket(Socket[addr=/127.0.0.1,port=32013,localport=3242])
>> DEBUG  | wrapperp | 2004/02/26 19:31:52 | accepted a socket from  
>> 127.0.0.1 on port 3242
>> DEBUG  | wrapperp | 2004/02/26 19:31:52 | read a packet KEY :  
>> VRxfE5Fd856GSIaF
>> DEBUG  | wrapper  | 2004/02/26 19:31:52 | Got key from JVM:  
>> VRxfE5Fd856GSIaF
>> DEBUG  | wrapperp | 2004/02/26 19:31:52 | send a packet LOW_LOG_LEVEL  
>> : 1
>> DEBUG  | wrapperp | 2004/02/26 19:31:52 | send a packet PING_TIMEOUT  
>> : 300
>> DEBUG  | wrapper  | 2004/02/26 19:31:52 | Start Application.
>> ....
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] Application output to Logfile

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

Barney,
    The Wrapper is designed to handle all output sent to the JVM's 
stdout and stderr
as INFO level log messages.   These should all be logged to the console and
wrapper.log files by default.  This can be changed depending on how you have
configured the wrapper.

   The ping messages are all DEBUG level messages.  If you are seeing 
them then you
should be seeing the JVM output as well.   Do you see the Wrapper version on
startup?  That comes from the stdout of the JVM.

    Is it possible that a logging tool inside the JVM is redirecting the 
console output
elsewhere?

Cheers,
Leif

bar...@on... wrote:

>Hi,
>
>usually, when I start the applcation, that I have, manually in the
>shell, I  got logoutputs to STDOUT.
>
>When I'm using wrapper I only have the wrapper output in the logfile
>(like jvw ping).
>How do I get the application output to my logfile ?
>
>thx in advance,
>Barney
>  
>

Re: [Wrapper-user] Disable jvm ping

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

Roger,
    Setting wrapper.ping.timeout=18000 should be working for you.  What 
do mean
when you say that the service died instantly?   Could you try enabling 
debug output
using the wrapper.debug=true property.  I would need to see the output 
to help you
narrow down the exact problem.

    The Wrapper normally handles high loads fairly well as long as the 
loads are not
being caused by low memory leading to the JVM's memory being cached to disk.

    As a note 3.1.0 includes a new optional tick based timer that so far 
looks like it
will perform much better under high loads.  That is in CVS and ready.  I 
still need
to find time to get the release out however.

Cheers,
Leif

Roger Choi wrote:

> Hi,
>
> Is there anyway to disable jvm ping function?  I hava an application 
> which could be under extremely heavy load sometimes (around 5 hours).  
> I have try to set the property wrapper.ping.timeout=18000
> But the service die instantly.
>
> Is there any workaround for this problem?
>
> Thank you.
>
> Regards,
>
> Roger

Re: [Wrapper-user] Problem with ServiceWrapper 3.0.5 and Tomcat

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

Stefan,
You say that your servlet makes use of a JNI native library to operate?  
Are you sure
that the library is correctly located on your library path.  When you 
run Tomcat
standalone the library path will default to looking on the PATH.   But 
when using the
Wrapper, you need to specifically specify the full library path in the 
wrapper.conf file.

This is not anything that has changed between 2.2.4 and 3.0.5 however.

Try setting the wrapper.debug=true property.   This will let you see the 
full library path
being used on startup and it may give some clues as to why exactly the 
application is
shutting down.

Is the problem servlet something that you have source for?  My guess is 
that it is calling
System.exit when it fails to locate its native library.  Because of your 
comment on
load_on_startup, I assume that this is happening in the servlet's init 
method.

Cheers,
Leif


sou...@m4... wrote:

> Hi,
>
> I recently used this smart tool (ServiceWrapper 2.2.4) for starting 
> Tomcat and everything worked fine (SimpleApp). Now I updated to 3.0.5 
> and am confronted with the strange problem that Tomcat shuts down 
> immediately after starting. I am clueless because no log contains any 
> error - it seems to stop right after a certain instruction.
>
> Recently I tracked it down to be a problem with a certain dynamic 
> servlet which is the main part of a server - client architecture -  
> therefore I cannot go on without using it ... Tomcat itself will start 
> without any problem if I do use its startup.bat.
> Also using the wrapper and Tomcat as a simple Webserver works ok but 
> in this case when I try to load the servlet on startup time Tomcat and 
> the wrapper also shut down immediately. If I leave out the 
> load-on-startup it shuts down right after the first call to the 
> servlets address.
>
> Additionally let me add that I am using another native dll in my 
> servlet for storing data. Could that cause any problems?
>
> Any help will be appreciated,
>  Stefan Dingfelder

Re: [Wrapper-user] What are reasons a service wouldn't be able to start?

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

Jennifer,
    I am not aware of any such limit other than simply running out of 
system resources.
I have never tried running more than a few instances at a time.  
Certainly never that
many.  It took a while, but I tried running 30 instances as services 
today.  They all
started up promptly without any problem.   They were all light weight test
applications which only used about 3MB each however.

    When your #24 service fails to start.  What are you getting in your 
wrapper.log?
Please try it with wrapper.debug set to true.   The message that you are 
getting
comes from the service manager if the service takes too long to start.  
The Wrapper
is designed to send signals to the ServiceManager in a timely fashion to 
prevent this
message from ever showing up.  What does your memory and CPU usage look like
when you are seeing this problem?

Cheers,
Leif

Jennifer Kolar wrote:

> In trying to start multiple instances of my application, and thus 
> multiple services I seem to hit a limit where no matter how long I 
> give for a startup timeout, I always get the response
>
>     Unable to start the serivce- The service did not respond to the 
> start or control request in a timely fashion.
>
> Any ideas?
> I seem to hit this at what would be service # 24 or 25.  I can start 
> more services via copying registry keys around directly.. I just can't 
> start them w/ the wrapper.exe ..
>
> thanks
> Jennifer

Re: [Wrapper-user] Service consumes 100% of dual-CPU resources

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

John,
    The problem with the corrupted log messages is a problem that I have 
fixed for the
3.1.0 release.  The logging code used a static buffer to build up the 
log messages
which was not thread safe.   99% of the Wrapper operates in a single 
thread so this is
not normally a problem.  The exceptions are log messages made from 
within a signal
handler and callbacks from the NT Service Manager.  Both of which are in 
other
threads.   This has all been fixed for the next release.  But other than 
corrupted
messages, this should not be causing any other problems because of the 
way the
buffer conflicts were taking place.  You are actually the only user I 
have heard from
this problem on.  I encountered it myself while developing 3.1.0 because 
that version
makes use of an additional timer thread which made the problem more obvious.

    As to your problem with the application eating 100% CPU,  could you 
give me
a little more information.   When the CPU is at 100%, what does the Task 
Manager
show?  Is the CPU being used by the JVM or by the Wrapper process?  
Other than
Jennifer's idea about sending large quantities of log events to the 
Event Logger (syslog)
I don't think this is your problem however because it does not appear as 
if you have
that much log output.  I don't have many ideas at this point.  I don't 
know of any
problems where the Wrapper has been responsible for this sort of problem.

    Another user had a similar problem a little while ago which was 
being caused by
a thread that was attempting to read from System.in.  The Wrapper does 
not allow
this and was throwing an exception.   The problem was that he had the 
read in a
try catch Throwable block which was in a while loop without any delay.  
This of
course consumed 100% CPU.  The code would work when not running under the
Wrapper.
    It is often useful to write a runner thread which catches and logs 
everything and
designed to never die.  But as a rule I always add a sleep(5000) after I 
log such
unexpected exception.  By doing this, it guarantees that the code will 
never enter
a state where it starts consuming 100% CPU.   Defensive programming.

    If the CPU is being used by the JVM rather than the Wrapper process, try
pressing CTRL-BREAK a couple times in the console.   This will cause it 
to dump
a full thread dump to the log.  You may get some clues by looking at 
what the
various threads are doing.

Cheers,
Leif
 

john yanlin wrote:

>Hi, All,
>
>We have been using the wrapper for some win NT services. Recently we
>occasionally ran into some problem where the services consume almost all
>(99%, 100%) the CPU resources of a dual-CPU machine. The following is a
>segment of the wrapper log file:
>
>=============================================================================
>INFO   | jvm 1    | 2004/02/18 06:31:25 | Send a packet 103 : ok
>DEBUG  | wrapperp | 2004/02/18 06:31:25 | read a packet 103 : ok
>DEBUG  | wrapper  | 2004/02/18 06:31:25 | Got ping response from JVM
>DEBUG  | wrapper  | 2004/02/18 06:31:26 | ServiceControlHandler(4)
>DEBUG  | wrapper  | 2004/02/18 06:31:26 |   SERVICE_CONTROL_INTERROGATE
>DEBUG  | wrapperp | 2004/02/18 06:31:31 | sent 6 bytes
>INFO   | jvm 1    | 2004/02/18 06:31:31 | Received a packet 103 : ping
>INFO   | jvm 1    | 2004/02/18 06:31:31 | Send a packet 103 : ok
>DEBUG  | wrapperp | 2004/02/18 06:31:31 | read a packet 103 : ok
>DEBUG  | wrapper  | 2004/02/18 06:31:31 | Got ping response from JVM
>DEBUG  | wrapperp | 2004/02/18 06:31:37 | sent 6 bytes
>DEBUG  | wrapper  | 2004/02/18 06:31:37 | ServiceControlHandler(4)
>Dvm 1    | 20E0UG4/02 | 18 06wrapper  | 31:37 | Received a packet 103 :
>ping
>Dvm 1    | 20E0UG4/02 | 18 06wrapper  | 31:37 | Received a packet 103 :
>ping
>2004/02/18 06:31:37 |   SERVICE_CONTROL_INTERROGATE
>STATUS | wrapper  | 2004/02/18 10:38:00 | --> Wrapper Started as Service
>DEBUG  | wrapperp | 2004/02/18 10:38:00 | server listening on port 17005.
>DEBUG  | wrapper  | 2004/02/18 10:38:00 | JVM was only running for
>-322562155 seconds leading to a failed restart count of 1.
>STATUS | wrapper  | 2004/02/18 10:38:00 | Launching a JVM...
>===================================================================================
>
>>From which we can see that at 6:31:37 something went wrong. There are two
>lines in the log are exactly the same and the contents are sort of mixed.
>It should be something like:
>
>DEBUG | wrapper | 2004/02/18 | 06:31:37 | Received a packet 103 : ping
>
>Instead, it came out mixed as:
>
>Dvm 1    | 20E0UG4/02 | 18 06wrapper  | 31:37 | Received a packet 103 :
>ping
>Dvm 1    | 20E0UG4/02 | 18 06wrapper  | 31:37 | Received a packet 103 :
>ping
>
>The DEBUG and the date time were mixed. There was a 'B' in the 'DEBUG'
>missing. the 'J' for 'Jvm 1' was also missing. During that time, the
>service shown active in the windows service manager panel. But the actual
>service was hung. 
>
>It seems that there was something happening inside the wrapper native
>part. Have anyone ever got the similar situation like this? Could anyone
>suggest what was happening here?
>
>Thanks,
>
>  
>

Re: [Wrapper-user] Wrapper directories

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

Andreas,
    Thanks for the reminder <:-)  I need to get around to implementing 
this.  The
feature request was logged way too long ago.   No it is not possible 
with the
current Wrapper.

https://sourceforge.net/tracker/index.php?func=detail&aid=738160&group_id=39428&atid=425190

Cheers,
Leif

Andreas Wendt wrote:

> Leif,
>
> is there a chance (in the current version 3.0.5 or in a future one) to 
> specifiy the starting directory for the wrapper from "outside" (e.g. 
> via an environment variable).
>
> I want to integrate with JBoss, but I don't want to copy the wrapper 
> files to the jboss directories. Since the wrapper isn't able to use 
> another starting directory other than the executable's (Windows) or 
> the starting script's one (Unix), JBoss will not be able to start 
> properly due to some relative paths when constructing its classpath 
> from its config files.
>
> TIA,
> Andreas
>

Re: [Wrapper-user] Network File Access Problem

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

Patrick,
    Sal's comment was correct.  But the recommended way of configuring 
an account is
to make use of the wrapper.ntservice.account and wrapper.ntservice.password
properties.  This way the account settings will survive the service 
being reinstalled.

Thanks Sal,
Cheers,
Leif
   
Sal Ingrilli wrote:

>by default services run under the system account which does NOT have access
>to the network.
>you need to set the account for your service to a domained user.
>the system account is different than the administrator account.
>
>control panels | administrative tools | services | your service | right
>click | properties | Log On
>click "This account"
>and enter an account/password that has access to //somemachine
>
>i suggest that you start by using your username/password
>
>-----Original Message-----
>From: wra...@li...
>[mailto:wra...@li...]On Behalf Of
>Pat...@ae...
>Sent: Monday, March 08, 2004 2:41 PM
>To: wra...@li...
>Subject: [Wrapper-user] Network File Access Problem
>
>
>Hi,
>
>I am attempting to write a program that accesses a file on different
>machine.
>
>In a simple standalone program, I can read the file fine. The following code
>produces "file.exists() = true":
>
>String logFilePath = "//somemachine/j2ee_home/myApp.log";
>File file = new File(logFilePath);
>System.out.println("file.exists() = " + file.exists() );
>
>However when I run the same code inside the Java Service Wrapper, the output
>is "file.exists() = false".  For some reason I can't access the file.
>
>Does anyone have any information on this problem?
>  
>

Re: [Wrapper-user] wrapperKillProcess()

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

Richard,

> Looking through the code in wrapper.c, the message:
>
> "JVM appears hung: Timed out waiting for signal from JVM."
>
> is printed when the primary process has not responded to a ping.
> Immediately after this the function wrapperKillProcess() is called.
> As far as I can see there were no "exit requests" prior to  the SIGKILL.
> Obviously, you are much more familiar than I am with the code, could
> you point out where a previous exit request was sent after
> the ping timeout so I can better understand the flow of control. Thanks.

The JVM was never asked to exit using a signal.  But the Wrapper does 
maintain a
socket which is used for all such communications.  In my experience when 
that
communication link has failed, the Wrapper can assume that the JVM is frozen
or at least in a very bad state.  This is one of the points at which the 
Wrapper will
attempt to kill the JVM.

>
> If there was no previous exit request, would there be any harm is
> first sending the process a SIGTERM followed (100 ms later or so)
> by a SIGKILL?

I went ahead and added this.  If the JVM is truly frozen it will not 
have any effect
as the JVM will not be able to respond to the SIGTERM.   This is why I 
was just
going ahead and sending the SIGKILL when I was convinced that the JVM was
dead.

As I understand it.  The kill function does not send the signal to the 
child processes
so I am not sure if this change will make any difference for the problem 
you are
having with the child processes.   It may be necessary to loop over any 
child
processes of the JVM, sending the SIGTERM then SIGKILL signals to each of
them.  (Need to look into whether or not this is even possible)

The additional debug information associated with this will be useful in 
detecting
whether the JVM is actually frozen or not.  It has the drawback of 
adding up to
5 seconds to the time that it takes to kill and then restart a frozen JVM.

It takes 24 hours for the public CVS archive to be synched with the dev 
archives.
But I would appreciate it if you could check out the CVS code, build and 
then
test this fix with your application.  I am interested to find out if it 
makes any
difference for you.

> As an aside, using the "unsupported" classes
> sun.misc.Signal and sun.misc.SignalHandler one can register
> signal handlers. At least on Linux using java 1.4.2_03 registering
> to catch TERM works but reqistering to catch KILL results in a
> nice core dump at the point of registration :-)

That is interesting to know about.  The Wrapper already supports this 
when you use
integration method #3.  You can receive any and all signals sent to the 
JVM using the
WrapperListener.controlEvent method.

Cheers,
Leif

Re: [Wrapper-user] disabling automatic shutdowns

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

Shmul,
    You are actually doing things correctly except for a minor detail.   
The wrapper.conf
file does not currently support having spaces around the '=' sign in the 
property names.
The way the conf file is parsed, the Wrapper will not see such 
properties.   I have
submitted the following bug and will get this fixed for a future version.
https://sourceforge.net/tracker/index.php?func=detail&aid=916001&group_id=39428&atid=425187

    For now, please go through and remove the spaces from the property 
definitions.
You should then be able to disable the pings.

    Cheers,
    Leif

Shmulik Regev wrote:

>I followed your advice and run the wrapper with debug information 
>switched on. Attached please find the log and the wrapper.conf file. 
>
>Please note that I'm not posting this file to the user group as I'm 
>not sure it is appropriate. However if you feel otherwise please tell 
>me. 
>
>I appreciate the help.
>
>
>Cheers,
>Shmul
>  
>

[Wrapper-user] Application output to Logfile

[<bar...@on...>]

Hi,

usually, when I start the applcation, that I have, manually in the
shell, I  got logoutputs to STDOUT.

When I'm using wrapper I only have the wrapper output in the logfile
(like jvw ping).
How do I get the application output to my logfile ?

thx in advance,
Barney