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

Re: [Wrapper-user] RE: JVM exit - no log error entries

[Paul C. <cas...@au...>]

Leif,

It's the JVM that is not always outputting a hotspot log when it crashes.
It seems odd that it does sometimes, and not others, when the crash is
produced by following a predefined sequence of events (same each time).

You're right - it's in the JVM.

Regards,

Paul Casanova



|---------+---------------------------------------->
|         |           Leif Mortenson               |
|         |           <le...@ta...>    |
|         |           Sent by:                     |
|         |           wra...@li...|
|         |           ceforge.net                  |
|         |                                        |
|         |                                        |
|         |           22/06/2004 03:53 PM          |
|         |           Please respond to            |
|         |           wrapper-user                 |
|---------+---------------------------------------->
  >--------------------------------------------------------------------------------------------------------------|
  |                                                                                                              |
  |       To:       wra...@li...                                                           |
  |       cc:                                                                                                    |
  |       Subject:  Re: [Wrapper-user] RE: JVM exit - no log error entries                                       |
  >--------------------------------------------------------------------------------------------------------------|




Paul Casanova wrote:

>The Wrapper (as always!) was behaving as it should.  Strange thing is -
>while reproducing exactly the same crash (ie, I've documented the exact
>steps to reproduce it), the JVM was inconsistent in generating a hotspot
>error log - and hence hotspot error output in the Wrapper log file.  Any
>timeout values I can tweak to make this more consistent?
>
>
The JVM process is crashing here, so the only possible timeout that
could have any
effect might be the wrapper.ping.timeout.   In this case I doubt that it
would be useful
however as the Wrapper is detecting that the JVM process is gone long
before the
timeout.

When you say inconsistent, what do you mean?  If the JVM is simply not
always
dumping out a HotSpot error, then that is internal to the JVM and is
most likely
a timing issue.
If the Wrapper is somehow clipping some of the output from the JVM then
that may
be something that I need to work on.  I know there used to be a problem
with this
when the dump stack trace on failed exit feature was enabled.

>I'll have to search the bug database to see if this is a new bug.  I've
>found some similar, but I need to investigate more thoroughly - when I
have
>time.
>
>
I know how that goes.
Good luck
Leif



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

Re: [Wrapper-user] RE: JVM exit - no log error entries

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

Paul Casanova wrote:

>The Wrapper (as always!) was behaving as it should.  Strange thing is -
>while reproducing exactly the same crash (ie, I've documented the exact
>steps to reproduce it), the JVM was inconsistent in generating a hotspot
>error log - and hence hotspot error output in the Wrapper log file.  Any
>timeout values I can tweak to make this more consistent?
>  
>
The JVM process is crashing here, so the only possible timeout that 
could have any
effect might be the wrapper.ping.timeout.   In this case I doubt that it 
would be useful
however as the Wrapper is detecting that the JVM process is gone long 
before the
timeout.

When you say inconsistent, what do you mean?  If the JVM is simply not 
always
dumping out a HotSpot error, then that is internal to the JVM and is 
most likely
a timing issue.
If the Wrapper is somehow clipping some of the output from the JVM then 
that may
be something that I need to work on.  I know there used to be a problem 
with this
when the dump stack trace on failed exit feature was enabled.

>I'll have to search the bug database to see if this is a new bug.  I've
>found some similar, but I need to investigate more thoroughly - when I have
>time.
>  
>
I know how that goes.
Good luck
Leif

Re: [Wrapper-user] RE: JVM exit - no log error entries

[Paul C. <cas...@au...>]

Leif,

The Wrapper (as always!) was behaving as it should.  Strange thing is -
while reproducing exactly the same crash (ie, I've documented the exact
steps to reproduce it), the JVM was inconsistent in generating a hotspot
error log - and hence hotspot error output in the Wrapper log file.  Any
timeout values I can tweak to make this more consistent?

I'll have to search the bug database to see if this is a new bug.  I've
found some similar, but I need to investigate more thoroughly - when I have
time.

Regards,

Paul Casanova



|---------+---------------------------------------->
|         |           Leif Mortenson               |
|         |           <le...@ta...>    |
|         |           Sent by:                     |
|         |           wra...@li...|
|         |           ceforge.net                  |
|         |                                        |
|         |                                        |
|         |           22/06/2004 02:22 PM          |
|         |           Please respond to            |
|         |           wrapper-user                 |
|---------+---------------------------------------->
  >--------------------------------------------------------------------------------------------------------------|
  |                                                                                                              |
  |       To:       wra...@li...                                                           |
  |       cc:                                                                                                    |
  |       Subject:  Re: [Wrapper-user] RE: JVM exit - no log error entries                                       |
  >--------------------------------------------------------------------------------------------------------------|




Paul,
    Kudos tracking that down.  I can imagine it was not fun.  Is it a
known Sun bug or
did you find something new?

    I wanted to confirm that you now believe that things are working
correctly as far as
the Wrapper is concerned.  The JVM was crashing due to this bug and the
Wrapper
was restarting it.

Cheers,
Leif

Paul Casanova wrote:

>Hi all,
>
>I now know that this problem is not Wrapper related, but I thought some
>readers may find this of interest.
>
>I have found that the JVM crash occurs in the Graphics2d.draw() method
when
>attempting to draw a black circle around a colored one: depending upon the
>scale used, it results in a stack overflow, which suggests too many
>recursive calls.
>
>This appears to be a JDK bug, as the only thing that is changing is the
>scaling of the image to be drawn.  The number of method calls etc does not
>change - except perhaps at the JVM level.
>
>Regards,
>
>Paul Casanova
>
>
>



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

Re: [Wrapper-user] Log4J problem.

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

Oded,
    What version of the Wrapper are you using?

    Starting with 3.1.0, the WrapperManager overrides the System.out and 
System.err
print streams with wrapper streams.   This was necessary to implement 
some logging
features.

    This should not have affected log4j as it should simply make use of 
the wrapped
streams as usual.  Other programs that do the same thing have been working
correctly.

    I am not a log4j user myself.  If you could write up a very simple 
java program
which demonstrates this problem then I will try running it both with and 
without the
Wrapper and attempt to find out where the problem, if any, is.   Getting 
me a
sample program helps out a lot as 95% of the time tracking down such 
problems
is often taken figuring out how to set up the test case.

Cheers,
Leif

Oded Blayer wrote:

> I am trying to use Java Service Wrapper on an application that uses log4j.
> The problem I encounter is that all of my log messages are going 
> directly into the wrapper log, instead of the logs I specified in my 
> log4j.xml config file.
> Is there any reason that the wrapper will override the Log4J?
> Is there a log4J.xml to the wrapper, to which I can add my appenders?

Re: [Wrapper-user] 64 Bit HPUX

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

Sunil,
    Sorry, I am still waiting for help getting a valid makefile for the 
HPUX platform.
The current release is only for 32 bit systems.  <:-)

    If anyone has a binary they can post, or is willing to help out with 
a makefile,
I would appreciate it.

    In the past, instructions for building the 64bit library have been 
posted.  These
even included a makefile for the 64 bit platform.   They are easily 
looked up in the
archives for this list.  In order to get the releases to go smoothly, I 
will need to have
a single makefile that can build either a library that works with both, 
or a library for
each platform.  To make things even more complicated, I would hopefully 
like to
be able to have the makefile run on a 32bit system as that is the 
hardware that is
currently available to do builds.  Several volunteers help out with 
builds on platforms
I do not have access to:
http://wrapper.tanukisoftware.org/doc/english/authors.html

Cheers,
Leif

Annam, Sunil wrote:

>Can I get 64-bit library to use wrapper on HP-UX? 
>I am not unix guy. Moreover, limited knowledge and access of UNIX system
>prevents me from compiling and creating library.
>
>Thanks,
>
>Sunil
>  
>

Re: [Wrapper-user] RE: JVM exit - no log error entries

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

Paul,
    Kudos tracking that down.  I can imagine it was not fun.  Is it a 
known Sun bug or
did you find something new?

    I wanted to confirm that you now believe that things are working 
correctly as far as
the Wrapper is concerned.  The JVM was crashing due to this bug and the 
Wrapper
was restarting it.

Cheers,
Leif

Paul Casanova wrote:

>Hi all,
>
>I now know that this problem is not Wrapper related, but I thought some
>readers may find this of interest.
>
>I have found that the JVM crash occurs in the Graphics2d.draw() method when
>attempting to draw a black circle around a colored one: depending upon the
>scale used, it results in a stack overflow, which suggests too many
>recursive calls.
>
>This appears to be a JDK bug, as the only thing that is changing is the
>scaling of the image to be drawn.  The number of method calls etc does not
>change - except perhaps at the JVM level.
>
>Regards,
>
>Paul Casanova
>
>  
>

Re: [Wrapper-user] W2K Service Accessing Network share in non-domain environment (workgroup)

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

Dan,
    Network drives on Windows are always a bit finicky.   Usually you 
will want to start
by getting things working in console mode while logged in as the user 
you will be
running as as a service.   If it doesn't work in console mode then it 
will not work as a
service.

    When running as a service, you must specify a user to run as if you 
wish to access
network or printer resources.  It sounds like you have this part figured 
out however.

    I am surprised that you are not about to make things work when 
running in console
mode.  In every case that I have seen, if you can see a drive in the 
file explorer, you
can also see it when running under console mode.  This is because any 
such drive will
already be logged in and connected at that point.

    I have seen problems on system startup when referencing mapped 
network drives
while running as a service.   It appears that such drives are not always 
actually
mapped until an actual user logs on to the system.  This is not true on 
all systems.
But I have seen it on a customer's W2k system.
    The solution was to reference the drive using the direct 
//x.x.x.x/share format
as you appear to be doing.

    Other than that I don't have any other advice at this point other 
than to suggest
double checking the drive URIs and the login information.

    Post back if you get any more info.

Cheers,
Leif
   

Dan Feather wrote:

>Hello,
>    I have a W2k system that is unable to access a network share on
>another W2k system. Basically I try to list the files in
>"//x.x.x.x/share" and I get null back from the list() method. I ran into
>this at another location, and set the service up to run as a
>specific user, and that fixed the problem there. However, it isn't working
>this time. The one difference I know of at this location is that they
>don't use a domain.
>    The crazy thing is, the user we are running the service as (the local
>administrator account) can browse the share and all that good stuff. We
>did run the wrapper from the command line with the -c option logged in as
>the same user to see if that would help, but that didn't work either. Has 
>anyone run into anything like this before? If so, were you able to fix it
>or did you have to work around it somehow? I
>appreciate any help or condolences!
>
>--
>P.S. List Admin. Sorry for the double post. The first time I sent it I
>didn't realized I had subscribed with the wrong e-mail address.
>
>  
>

Re: [Wrapper-user] Separate System.out and System.err in different log files

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

Edi,
    This is on my list of things to get implemented.  It is currently 
not possible to break
the system.err and system.out into two separate log files from the Wrapper.

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

    I describe a work around in the feature request.  If you have any 
comments on how
you would like to see it implemented, please add them there.

Cheers,
Leif


Edi Carreras wrote:

> Hi All.
>  
> Well that's my question. Is it possible to have 2 separate log files 
> with system.out and system.err? They appear mixed in the logfile 
> defined...
>  
> Thanks.

Re: [Wrapper-user] Extending Timeouts error

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

Andre,
    Sorry for the slow reply.   The message that you posted is actually not
a problem.   It is simply saying that the Wrapper and JVM processes did
not receive any CPU for 5389 seconds.  Then notifying you that it has
extended all of its internal timeouts appropriately.
    If the JVM was actually hung then the Wrapper would have told you that
it timed out waiting for a response from the JVM and the JVM would have
been restarted.  I don't think that your JVM was having any problems at this
point.

    This can happen for a number of reasons.
1) Another process is consuming 100% of all CPU at a high priority for
a long period of time.   Some backup systems do this.

2) Your system was suspended to memory or disk for the specified time
and then restored.

3) Your system time was set forward by 5389 seconds.

    The current default timing mechanism of the Wrapper is based off of the
system time and is affected by system time changes and other applications
consuming lots of CPU.   In most cases the Wrapper recovers correctly
with no ill effects, but at times you can end up with the JVM being 
restarted.
For example setting the system time back by more than 30 seconds or so
will often result in the JVM being restarted.

    To resolve these problems, a tick based timer mechanism was added in
version 3.1.0.   It is still considered experimental until it has had a 
chance to
get more live testing.   The 3.1.0 release had a few related bugs on 
multi cpu
systems.  But they have been fixed in the 3.1.1 release.  If no further
problems are discovered in that release then I will most likely make it the
default timer for the 3.1.2 or 3.1.3 release.

Cheers,
Leif


Andre Harry wrote:

>Hi,
>
>Im using version 3.0.2
>
>and it's been running okay for a while but recently
>we're having problems, it keeps crashing and sometimes
>just hung. However, the service is not restarted as it
>is said on the website. We didnt realise it until the
>next day that it crashed.
>
>Sometimes there's no error message in the log file, it
>just exited, however today i have this error message:
>
>INFO   | wrapper  | 2004/06/02 10:18:21 | Wrapper
>Process has not received
>any CPU time for 5389 seconds.  Extending timeouts.
>INFO   | jvm 1    | 2004/06/02 10:18:21 | JVM Process
>has not received any
>CPU time for 5388 seconds.  Extending timeouts.
>
>and i dont know understand what the problem is. And
>how to make the service restarts automatically? do i
>need to set it up in the config file? or should it be
>done automatically?
>
>Thanks for the help
>Andre
>  
>

Re: [Wrapper-user] configuration file

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

Johan,
    It is not possible to reference Java system properties from within 
the Wrapper
configuration file.   The file has to be read and parsed long before the 
JVM is ever
launched so this will not be possible.

    In your particular case however, the java.io.tmpdir property simply 
maps to the
the TEMP environment variable.  So you can get the behavior you are 
looking for
by doing the following:
wrapper.logfile=%TEMP%/wrapper.log

    Note that on XP, the TEMP directory maps to something like:
C:\Documents and Settings\leif\Local Settings\Temp

    (By the way if you have ever wondered where all of your hard disk 
space was
going...  Check this directory once in a while....  Various programs 
seem to like
putting things here and then forgetting about them...)

Stuijt, Johan wrote:

> Hello,
>
>  
>
> Is it possible to reference Java System Properties from within the 
> wrapper configuration file just like you can reference Environment 
> Variables?
>
> In this case it has to do with the location of the log-files for the 
> wrapped java processes.
>
> The processes themselves write their logfiles in the directory given 
> through Java System Property "java.io.tmpdir", and I want the wrapper 
> logfile to end up in that same directory.
>
>  
>
> Is it possible to change the logfile spec from within the running 
> wrapped application?
>
> Example: WrapperManager.setLog(System.getProperty("java.io.tmpdir") + 
> "/my_log.file");
>
>  
>
> Am using wrapper 3.0.5. on Linux rh9 and Win2K.
>
>  
>
> Thanks,
>
>  
>
> Johan Stuijt
>
> Met vriendelijke groet,
> Johan Stuijt
> Application Engineer
> MES Expert Center
> Doorkiesnummer: 075 612 79 34
>  
> *GTI Industrie Noordwest bv*
> *        **Industrial Automation*
>
> *       * Houthavenkade 44  1506 PD Zaandam
> *       * Postbus 1377  1500 AJ Zaandam
> *       * tel.: 075 612 76 00   fax: 075 612 30 60
>         www.gti-group.com/ia <http://www.gti-group.com/ia>
>
>  
>

Re: [Wrapper-user] Wrapper.dll not loaded with JDK 1.4

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

Jeremy,
    Sorry for the delay.   I just tried this out on an XP system with 
1.4.2_04 and it
worked for me without any problems.   I had only used 1.4.2_03 up to 
this point.
I have not heard of any problems using 1.4.x JVMs and make use of them 
regularly.
    I will try this out on a 2000 machine when I get home tonight.  I 
have used other
1.4.x versions on that machine, but have not yet tried out 1.4.2_04.

    Could you try downloading the wrapper release and then running the
bin\TestWrapper.bat script?  I am curious to see how that works on these
systems.   The default config file uses the path to locate the JVM, so 
you probably
want to modify it to point to a specific JVM for your tests.

    I am not sure how you are testing between the 1.3.x and the 1.4.x 
versions of
the JVM.   But is it possible that your build process could be somehow 
corrupting
the DLL?  If the TestWrapper demo app works then this would be my next 
guess.

    Also, try setting the wrapper.debug=true property when launching 
your program.
This will cause the JVM version information to be displayed in the log.  
You can use
this to verify that you are indeed running the JVM you are thinking you are.

Cheers,
Leif

Jeremy Fujimoto-Johnson wrote:

> I have discovered that when I start the JavaServiceWrapper and it's 
> pointing to the 1.4.2_04 JDK (e.g. 
> wrapper.java.command=C:/j2sdk1.4.2_04/bin/java) it fails to load the 
> wrapper.dll library. I get the following test in the log:
> STATUS | wrapper  | 2004/06/07 14:23:13 | --> Wrapper Started as Service
> STATUS | wrapper  | 2004/06/07 14:23:13 | Launching a JVM...
> INFO   | jvm 1    | 2004/06/07 14:23:15 | WARNING - Unable to load the 
> Wrapper's native library 'wrapper.dll'.
> INFO   | jvm 1    | 2004/06/07 14:23:15 |           The file is 
> located on the path at the following location but
> INFO   | jvm 1    | 2004/06/07 14:23:15 |           could not be loaded:
> INFO   | jvm 1    | 2004/06/07 14:23:15 |             
> C:\Tomcat\VAP\bin\..\common\lib\wrapper.dll
> INFO   | jvm 1    | 2004/06/07 14:23:15 |           Please verify that 
> the file is readable by the current user
> INFO   | jvm 1    | 2004/06/07 14:23:15 |           and that the file 
> has not been corrupted in any way.
> INFO   | jvm 1    | 2004/06/07 14:23:15 |           System signals 
> will not be handled correctly.
> INFO   | jvm 1    | 2004/06/07 14:23:15 |
> INFO   | jvm 1    | 2004/06/07 14:23:15 | Wrapper (Version 3.1.0) 
> http://wrapper.tanukisoftware.org
>  
> The same problem occurs when specifying JDK 1.4.1_07.
>  
> However, when I use the 1.3.1_07 version of the JDK this problem does 
> not occur.
>  
> I am using the JavaServiceWrapper to run Tomcat 4.0.6 on Windows 2000. 
> I have tried a couple of different Tomcat installs (different PCs and 
> even different WebApps). I can reproduce the behavior using both 3.0.5 
> and 3.1.0 of the JavaServiceWrapper. (Both the problem when using 1.4 
> and not having a problem with 1.3.1_07 can be reproduced on multiple 
> computers.)
> Is this a known conflict? I haven't been able to find any message in 
> the mailing list that seemed to directly apply.
> Is there anything I can do to get it to work? Is there a version of 
> the 1.4 JDK with which this problem does not occur?
> Thanks,
> -Jeremy
>  

Re: [Wrapper-user] Re: How do we config the wrapper??

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

Martin,

Chow, Martin wrote:

> I just want to update what I did so far after receiving your 
> suggestions. I make sure that my log directory exist in the correct 
> relative location to the wrapper.exe. It turns out that I didn’t 
> specify the path correctly. In the wrapper.conf, I put in 
> wrapper.logfile=../log/wrapper.log. If I change this configuration to 
> wrapper.logfile=..\log\wrapper.log, I was able to create the wrapper 
> log file in the correct location (in my log directory and not the 
> default location). After the wrapper log is created and placed in the 
> correct directory, I was able to set the size and number of log files 
> (max log size and number of files before overwriting the existing log 
> file). Therefore, the problem seems to be the way I put in the ‘\’ or 
> ‘/’ for the log file configuration.
>
What platform are you using? Windows X? I have used the Wrapper on NT, 2000
and XP. In all cases using the forward slashes without any problems.

At any rate, I put in a fix for the 3.1.1 release to always convert '/' 
to '\' characters
in that property on Windows. Back slashes do not work on UNIX platforms and
it is important that the wrapper.conf file can be used on any platform 
unmodified.

> I do however have any similar problem in the configuration. I wonder 
> if you or anyone tries to disable the wrapper log file. According to 
> the documentation, if I give a blank value for wrapper.logfile 
> property, it will disable file logging. What do you mean by blank 
> value?? I try by setting (wrapper.logfile= ) and the wrapper just 
> default the wrapper log file to the default location. I also try erase 
> the entire (wrapper.logfile= ), but I still get a default log file in 
> the default location.
>
You have found a bug which it looks like was introduced way back in 
version 2.2.5.
Obviously not many people are interested in disabling the log file :-)

Anyway, you were doing this correctly:
wrapper.logfile=

The problem was that the Wrapper as is was trying to open a file called 
"". That
of course failed so it fell back to the default. This has been fixed and 
will be in the
3.1.1. release that is trying to get out the door. :-)

Cheers,
Leif

Re: [Wrapper-user] How do we config the wrapper??

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

Martin,

Chow, Martin wrote:

> I am trying to configure a couple of things here. But it does not seem 
> to take effect when I restart the service. I try different 
> combinations to see if which properties will take effect after I 
> restart the service.
>
> 1) I try to change the log file wrapper.logfile=../log/wrapper.log to 
> try to tell the wrapper to write the log file in the directory called 
> “log”. Every time I run the service, the wrapper creates a default log 
> file in the same directory as my wrapper executable.
>
If the Wrapper is unable to write to the specified log file for any 
reason then it will
fall back to writing to a file called wrapper.log in the same directory 
as the
Wrapper.exe is located. This is the correct behavior.

There are a number of reasons why the Wrapper may not be able to write
to the ../log/ directory.
1) Make sure the directory exists. This relative location should be 
relative to
the location of the Wrapper.exe
2) Does this work correctly when you are running in console mode rather than
as a service? If so, it is possible that this is a permission problem. 
Make sure
that you have not configured the log directory in such a way that the user
running the Wrapper is not able to write to. By default, the Wrapper runs as
the SYSTEM user when running as a service.

> 2) Second, I try to limit the maximum size of my log file before a 
> roll over occurs. For example, wrapper.logfile.maxsize=285k. After the 
> default wrapper log is over 285kb, no new log file is created. The 
> size of my wrapper log will keep increasing until I decrease the 
> wrapper log.
>
This is actually the correct behavior given #1. The Wrapper will not 
attempt to
do any log rolling of the fall back log file. That only works on the 
configured
log file.

> I did however, successfully configure the wrapper.console.format => 
> from wrapper.console.format=LPTM to wrapper.console.format=PM. The 
> format did change after I restart the service.
>
This format change works in the fall back file.

> Therefore, I am sure my configuration is correct. Please suggest how I 
> can configure the rolling of the wrapper log (Problem 2), and also how 
> we can tell the wrapper to create the wrapper log in where we specify 
> (Problem 1).
>
> I have attached my configuration file for reference.
>
I only got the section where you are defining the logging. But from what 
I can see,
everything looks ok. Once you solve #1, everything should start working 
correctly.

Cheers,
Leif

Re: [Wrapper-user] RE: JVM exit - no log error entries

[Paul C. <cas...@au...>]

Hi all,

I now know that this problem is not Wrapper related, but I thought some
readers may find this of interest.

I have found that the JVM crash occurs in the Graphics2d.draw() method when
attempting to draw a black circle around a colored one: depending upon the
scale used, it results in a stack overflow, which suggests too many
recursive calls.

This appears to be a JDK bug, as the only thing that is changing is the
scaling of the image to be drawn.  The number of method calls etc does not
change - except perhaps at the JVM level.

Regards,

Paul Casanova



|---------+---------------------------------------->
|         |           Leif Mortenson               |
|         |           <le...@ta...>    |
|         |           Sent by:                     |
|         |           wra...@li...|
|         |           ceforge.net                  |
|         |                                        |
|         |                                        |
|         |           11/06/2004 03:06 PM          |
|         |           Please respond to            |
|         |           wrapper-user                 |
|---------+---------------------------------------->
  >--------------------------------------------------------------------------------------------------------------|
  |                                                                                                              |
  |       To:       wra...@li...                                                           |
  |       cc:                                                                                                    |
  |       Subject:  Re: [Wrapper-user] RE: JVM exit - no log error entries                                       |
  >--------------------------------------------------------------------------------------------------------------|




Paul,
    I need to get caught up on mail...

    I looked in the MSVC docs and found that the error code 128 is
ERROR_WAIT_NO_CHILDREN, which has the description
"There are no child processes to wait for."

    When the Wrapper has decided that the JVM process is gone, the
Wrapper makes a call to get that process's exit code which is being
returned as 128 in your case.   That might make sense if that process
at died abnormally and simply went away...   From the log info there
is not really any useful information about what might have happened
to it however.

    If I kill the process with the task manager, I am getting an exit code
of 1.   But in that case, the system is still bringing the process down
reasonably cleanly.

    What platform are you using?  I am assuming Windows at the moment.

Cheers,
Leif

128          There are no child processes to wait for.
ERROR_WAIT_NO_CHILDREN


Paul Casanova wrote:

>
>
>Hi again.
>
>I'm now able to replicate this JVM exit consistently, so I turned on
debug.
>However, I only got 1 more line of logging:
>
>DEBUG  | wrapper  | 2004/06/11 08:46:07 | Got ping response from JVM
>INFO   | jvm 1    | 2004/06/11 08:46:09 |
>DEBUG  | wrapper  | 2004/06/11 08:46:09 | JVM process exited with a code
of
>128, setting the wrapper exit code to 128.
>ERROR  | wrapper  | 2004/06/11 08:46:09 | JVM exited unexpectedly.
>DEBUG  | wrapper  | 2004/06/11 08:46:09 | Waiting 5 seconds before
>launching another JVM.
>STATUS | wrapper  | 2004/06/11 08:46:13 | Launching a JVM...
>
>I've done a search in the Java forums and on the web, but can't find any
>info on the exit code 128 for the JVM.
>
>Has anyone seen something like this before, or does any have any other
>ideas / suggestions?
>
>Regards,
>
>Paul Casanova
>
>
>
>Hi all,
>
>Our application crashed this morning after a user attempted a print using
a
>Lexmark Optra Color 45 driver.  We haven't had an issue with this driver
>before, so it has me baffled.
>
>Here's a timeline of the facts that I can gather:
>9:38:05     A blank line was logged by the Java Service Wrapper. This
>suggests that an error was thrown by the JVM, but it didn't get to log it
>because:
>9:38:06     The JVM exited without any error information.
>9:38:06     The Windows Event Log shows the Lexmark Optra Color 45
>completing a print process (ie generating a plot file) - although the
>resultant file was 0 bytes in length.
>
>A PrinterException should have been thrown by the printing process, but it
>shouldn't have made the JVM crash.
>
>We're using 1.3.1_11.
>
>Here's the output of the JSW log file at that time:
>
>INFO   | jvm 1    | 2004/06/09 09:38:05 |
>ERROR  | wrapper  | 2004/06/09 09:38:06 | JVM exited unexpectedly.
>STATUS | wrapper  | 2004/06/09 09:38:10 | Launching a JVM...
>INFO   | jvm 2    | 2004/06/09 09:38:10 | Wrapper (Version 3.1.0)
>http://wrapper.tanukisoftware.org
>INFO   | jvm 2    | 2004/06/09 09:38:10 |
>
>Why the blank lines?
>
>There had been no activity between 9.34 and 9.38am, so the info above this
>in the log file is not relevant.
>
>I thought I had the JSW configured to dump out thread stuff on exit.
>Here's my conf details:
>
># Request a thread dump on JVM exit
>wrapper.request_thread_dump_on_failed_jvm_exit=true
>
>#********************************************************************
># Wrapper Logging Properties
>#********************************************************************
>wrapper.console.format=LPTM
>wrapper.console.loglevel=INFO
>wrapper.logfile=%RCIS_HOME%\Service\logs\RCISMainServer.log
>wrapper.logfile.format=LPTM
>wrapper.logfile.loglevel=INFO
>wrapper.logfile.maxsize=1m
>wrapper.logfile.maxfiles=100
>wrapper.syslog.loglevel=ERROR
>
># Allow the service to interact with the desktop.
>wrapper.ntservice.interactive=false
>
># Disable the wrapper startup timeout facility
>wrapper.startup.timeout=0
>
># Enable the wrapper exit timeout facility so that the JVM will be
>terminated if shutdown fails
>wrapper.jvm_exit.timeout=120
>
># Enable the wrapper shutdown timeout facility so that the JVM will be
>terminated if shutdown fails
>wrapper.shutdown.timeout=120
>
># Extend the wrapper ping timeout facility to prevent restarting under
>normal operation (10 minutes)
>wrapper.ping.timeout=300
>
>Does this all look reasonable?  I'd rather not have debug on all the time
>if we can get away with it - a problem like this might not occur for
>another few months, but I'd like to be able to explain it to the client
>when and if it does.
>
>Any ideas would be greatly appreciated.
>
>Regards,
>
>Paul Casanova
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by the new InstallShield X.
>>From Windows to Linux, servers to mobile, InstallShield X is the
>one installation-authoring solution that does it all. Learn more and
>evaluate today! http://www.installshield.com/Dev2Dev/0504
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...
>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>
>



-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the
one installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] problems using dll inside wrapper

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

Kristian,
    I have not used COM myself.  But there was another user several 
months back you
had been having problems using the Wrapper.   I added an FAQ entry 
covering the
subject:

http://wrapper.tanukisoftware.org/doc/english/faq.html

    Post back if that doesn't help.   Try hard coding your java.exe 
location into the
wrapper.conf with a fully qualified path.  The path is not always what 
you are
expecting.  Especially when running as a service.

Cheers,
Leif

kri...@st... wrote:

>Hello,
>I have a java program that calls native code in a statically linked dll. Outside
>the wrapper there are no problems. My native code invokes a ms office
>application through the COM IDispatch interface. 
>My application starts fine inside the wrapper to begin with. The first call to
>the dll succeds(simply starting the office application and establishing a
>reference to it) but on subsequent calls the dll is unable to maintain the
>reference to the com object and crashes. Im using what is called integration
>method one, with no modification to my source code. 
>Im running jre 1.4.1, os win2k professional. 
>Does anyone have any ideas of what the wrapper does that can cause such a behavior? 
>
>Kristian Skotte 
>  
>

[Wrapper-user] problems using dll inside wrapper

[<kri...@st...>]

Hello,
I have a java program that calls native code in a statically linked dll. Outside
the wrapper there are no problems. My native code invokes a ms office
application through the COM IDispatch interface. 
My application starts fine inside the wrapper to begin with. The first call to
the dll succeds(simply starting the office application and establishing a
reference to it) but on subsequent calls the dll is unable to maintain the
reference to the com object and crashes. Im using what is called integration
method one, with no modification to my source code. 
Im running jre 1.4.1, os win2k professional. 
Does anyone have any ideas of what the wrapper does that can cause such a behavior? 

Kristian Skotte 

Re: [Wrapper-user] Running Sun Java System Application Server 8.0 as a Windows service?

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

Sean,
    I have not tried that particular application in the past.  It should 
be fairly easy for you
to do so yourself however.  Take a look at the Integration 
documentation.  Once you
have done that I would be happy to help with any problems encountered.

http://wrapper.tanukisoftware.org/doc/english/integrate.html

Cheers,
Leif
 
Sean C. Sullivan wrote:

> I installed Sun's Java System Application Server 8.0 (Platform 
> Edition) on Windows XP.
>
> I would like to run the app server as a Windows service.
>
> Has anybody tried this already?
>
> Link:  
> http://www.theserverside.com/discussions/thread.tss?thread_id=26387
>
> -Sean
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

[Wrapper-user] Running Sun Java System Application Server 8.0 as a Windows service?

[Sean C. S. <se...@se...>]

I installed Sun's Java System Application Server 8.0 (Platform Edition) 
on Windows XP.

I would like to run the app server as a Windows service.

Has anybody tried this already?

Link:  http://www.theserverside.com/discussions/thread.tss?thread_id=26387

-Sean

Re: [Wrapper-user] Error in WrapperListener.stop callback

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

Tim,
    I am not sure what the second line of the stack trace is?  Did you 
copy it straight
from the log? There is no way that the 
WrapperManager.isControlledByNativeWrapper
method could be throwing an NPE.  But I don't think that is what this 
stack trace
is showing anyway.

Error in WrapperListener.stop callback.  java.lang.NullPointerException
java.lang.NullPointerExceptionisControlledByNativeWrapper
at 
com.lmco.itis.fis.server.ApplicationMain.stopServer(ApplicationMain.java:26)
at MainWrapper.stop(MainWrapper.java:61)
<snip>

    This looks like your ApplicationMain.stopServer method is throwing a NPE
on line 26?  This is your code isn't it?

    From what I can see, the Wrapper is catching and reporting this problem
correctly.

Let me know if I am missing something.

Cheers,
Leif

Cobble, Tim wrote:

> All,
>
>  
>
> Using the integration method of the wrapper.  Attempting to call 
> custom code in the stop method.  Errors received.
>
>  
>
> I know I am calling into my custom code due to the console output of 
> "Calling pauseServer"  But I am not able to stop the threads, 
> something bails out.  This is existing code that I know works, just 
> calling it from the wrapper.
>
>  
>
> Pasting Code, and Errors from both the console output and the log file.
>
>  
>
> Any help would be most appreciated!!!!
>
>  
>
> Tim
>
>  
>
>      C O D E
>
> ------------------------------------------------------------------------------------------------------------------------------
>
> import org.tanukisoftware.wrapper.WrapperManager;
> import org.tanukisoftware.wrapper.WrapperListener;
> import com.lmco.itis.fis.server.*;
>                    
> public class MainWrapper
>     implements WrapperListener
> {
>     private ApplicationMain m_app;
>
>  
>
>     /*---------------------------------------------------------------
>      * Constructors
>      *-------------------------------------------------------------*/
>     private MainWrapper()
>     {
>     }
>
>  
>
>     /*---------------------------------------------------------------
>      * WrapperListener Methods
>      *-------------------------------------------------------------*/
>     public Integer start( String[] args )
>     {
>          m_app = new ApplicationMain();
>          m_app.main(args);
>         //_m_app.start_ <file:///%5C%5Cm_app.start>();
>
>  
>
>         return null;
>     }
>
>  
>
>     /**
>      *
>      * @param exitCode The suggested exit code that will be 
> retJ4RcuQ71YLurned to the OS
>      *                 when the JVM exits.
>      *
>      * @return The exit code to actually return to the OS.  In most 
> cases, this
>      *         should just be the value of exitCode, however the user 
> code has
>      *         the option of changing the exit code if there are any 
> problems
>      *         during shutdown.
>      */
>     public int stop( int exitCode )
>     {
>          System.out.println("The Stop Method Got Called.");
>          WrapperManager.signalStopping(60000);
>          m_app.stopServer();
>        
>         return exitCode;
>     }
>    
>     /**
>      * Called whenever the native wrapper code traps a system control 
> signal
>      *  against the Java process.  It is up to the callback to take 
> any actions
>      *  necessary.  Possible values are: 
> WrapperManager.WRAPPER_CTRL_C_EVENT,
>      *    WRAPPER_CTRL_CLOSE_EVENT, WRAPPER_CTRL_LOGOFF_EVENT, or
>      *    WRAPPER_CTRL_SHUTDOWN_EVENT
>      *
>      * @param event The system control signal.
>      */
>     public void controlEvent( int event )
>     {
>         if (WrapperManager.isControlledByNativeWrapper()) 
>         {
>             // The Wrapper will take care of this event
>              System.out.println("isControlledByNativeWrapper");
>              WrapperManager.stop(0);
>         } 
>         else
>          {
>             // We are not being controlled by the Wrapper, so
>             //  handle the event ourselves.
>             if ((event == WrapperManager.WRAPPER_CTRL_C_EVENT) ||
>                 (event == WrapperManager.WRAPPER_CTRL_CLOSE_EVENT) ||
>                 (event == WrapperManager.WRAPPER_CTRL_SHUTDOWN_EVENT))
>          {
>                   System.out.println("In the wrapper_ctrl block");
>                   WrapperManager.stop(0);
>           }
>         }
>     }
>    
>     /*---------------------------------------------------------------
>      * Main Method
>      *-------------------------------------------------------------*/
>     public static void main( String[] args )
>     {
>         WrapperManager.start( new MainWrapper(), args );
>     }
> }
>
>  
>
>  
>
>  
>
>      L O G
>
> ------------------------------------------------------------------------------------------------------------------------------
>
> STATUS | wrapper  | 2004/06/15 08:12:45 | --> Wrapper Started as Console
> STATUS | wrapper  | 2004/06/15 08:12:45 | Launching a JVM...
> INFO   | jvm 1    | 2004/06/15 08:12:47 | Wrapper (Version 3.1.0) 
> _http://wrapper.tanukisoftware.org_
> INFO   | jvm 1    | 2004/06/15 08:12:47 |
> STATUS | wrapper  | 2004/06/15 08:17:26 | CTRL-C trapped.  Shutting down.
> INFO   | jvm 1    | 2004/06/15 08:17:26 | The Stop Method Got Called.
> INFO   | jvm 1    | 2004/06/15 08:17:26 | Calling pauseServer
> INFO   | jvm 1    | 2004/06/15 08:17:26 | Error in 
> WrapperListener.stop callback.  java.lang.NullPointerException
> INFO   | jvm 1    | 2004/06/15 08:17:26 | 
> java.lang.NullPointerExceptionisControlledByNativeWrapper
> INFO   | jvm 1    | 2004/06/15 08:17:26 |
> INFO   | jvm 1    | 2004/06/15 08:17:26 |  at 
> com.lmco.itis.fis.server.ApplicationMain.stopServer(ApplicationMain.java:26)
> INFO   | jvm 1    | 2004/06/15 08:17:26 |  at 
> MainWrapper.stop(MainWrapper.java:61)
> INFO   | jvm 1    | 2004/06/15 08:17:26 |  at 
> org.tanukisoftware.wrapper.WrapperManager.stopInner(WrapperManager.java:1903)
> INFO   | jvm 1    | 2004/06/15 08:17:26 |  at 
> org.tanukisoftware.wrapper.WrapperManager.handleSocket(WrapperManager.java:2312)
> INFO   | jvm 1    | 2004/06/15 08:17:26 |  at 
> org.tanukisoftware.wrapper.WrapperManager.run(WrapperManager.java:2602)
> INFO   | jvm 1    | 2004/06/15 08:17:26 |  at 
> java.lang.Thread.run(Thread.java:536)
> STATUS | wrapper  | 2004/06/15 08:17:27 | <-- Wrapper Stopped
>
>  
>
>  
>
>  
>
>  
>
>      C O N S O L E
>
> ------------------------------------------------------------------------------------------------------------------------------
>
> wrapper  | --> Wrapper Started as Console
> wrapper  | Launching a JVM...
> jvm 1    | Wrapper (Version 3.1.0) _http://wrapper.tanukisoftware.org_
> jvm 1    |
> wrapper  | CTRL-C trapped.  Shutting down.
> jvm 1    | The Stop Method Got Called.
> jvm 1    | Calling pauseServer
> jvm 1    | Error in WrapperListener.stop callback.  
> java.lang.NullPointerException
> jvm 1    | java.lang.NullPointerExceptionisControlledByNativeWrapper
> jvm 1    |
> jvm 1    |      at 
> com.lmco.itis.fis.server.ApplicationMain.stopServer(ApplicationMain.java:26)
> jvm 1    |      at MainWrapper.stop(MainWrapper.java:61)
> jvm 1    |      at 
> org.tanukisoftware.wrapper.WrapperManager.stopInner(WrapperManager.java:1903)
> jvm 1    |      at 
> org.tanukisoftware.wrapper.WrapperManager.handleSocket(WrapperManager.java:2312)
> jvm 1    |      at 
> org.tanukisoftware.wrapper.WrapperManager.run(WrapperManager.java:2602)
> jvm 1    |      at java.lang.Thread.run(Thread.java:536)
> wrapper  | <-- Wrapper Stopped
> Terminate batch job (Y/N)?
>

[Wrapper-user] Error in WrapperListener.stop callback

[Cobble, T. <tim...@lm...>]

All,
 
Using the integration method of the wrapper.  Attempting to call custom
code in the stop method.  Errors received.
 
I know I am calling into my custom code due to the console output of
"Calling pauseServer"  But I am not able to stop the threads, something
bails out.  This is existing code that I know works, just calling it
from the wrapper.
 
Pasting Code, and Errors from both the console output and the log file.
 
Any help would be most appreciated!!!!
 
Tim
 
     C O D E 
------------------------------------------------------------------------
------------------------------------------------------
import org.tanukisoftware.wrapper.WrapperManager;
import org.tanukisoftware.wrapper.WrapperListener;
import com.lmco.itis.fis.server.*;
                    
public class MainWrapper
    implements WrapperListener
{
    private ApplicationMain m_app;
 
    /*---------------------------------------------------------------
     * Constructors
     *-------------------------------------------------------------*/
    private MainWrapper()
    {
    }
 
    /*---------------------------------------------------------------
     * WrapperListener Methods
     *-------------------------------------------------------------*/
    public Integer start( String[] args )
    {
         m_app = new ApplicationMain();
         m_app.main(args);
        //m_app.start <file:///\\m_app.start> ();
 
        return null;
    }
 
    /**
     *
     * @param exitCode The suggested exit code that will be
retJ4RcuQ71YLurned to the OS
     *                 when the JVM exits.
     *
     * @return The exit code to actually return to the OS.  In most
cases, this
     *         should just be the value of exitCode, however the user
code has
     *         the option of changing the exit code if there are any
problems
     *         during shutdown.
     */
    public int stop( int exitCode )
    {
         System.out.println("The Stop Method Got Called.");
         WrapperManager.signalStopping(60000);
         m_app.stopServer();
        
        return exitCode;
    }
    
    /**
     * Called whenever the native wrapper code traps a system control
signal
     *  against the Java process.  It is up to the callback to take any
actions
     *  necessary.  Possible values are:
WrapperManager.WRAPPER_CTRL_C_EVENT, 
     *    WRAPPER_CTRL_CLOSE_EVENT, WRAPPER_CTRL_LOGOFF_EVENT, or 
     *    WRAPPER_CTRL_SHUTDOWN_EVENT
     *
     * @param event The system control signal.
     */
    public void controlEvent( int event )
    {
        if (WrapperManager.isControlledByNativeWrapper()) 
        {
            // The Wrapper will take care of this event
             System.out.println("isControlledByNativeWrapper");
             WrapperManager.stop(0);
        } 
        else 
         {
            // We are not being controlled by the Wrapper, so
            //  handle the event ourselves.
            if ((event == WrapperManager.WRAPPER_CTRL_C_EVENT) ||
                (event == WrapperManager.WRAPPER_CTRL_CLOSE_EVENT) ||
                (event == WrapperManager.WRAPPER_CTRL_SHUTDOWN_EVENT))
         {
                  System.out.println("In the wrapper_ctrl block");
                  WrapperManager.stop(0);
          }
        }
    }
    
    /*---------------------------------------------------------------
     * Main Method
     *-------------------------------------------------------------*/
    public static void main( String[] args )
    {
        WrapperManager.start( new MainWrapper(), args );
    }
}
 
 
 
     L O G
------------------------------------------------------------------------
------------------------------------------------------
STATUS | wrapper  | 2004/06/15 08:12:45 | --> Wrapper Started as Console
STATUS | wrapper  | 2004/06/15 08:12:45 | Launching a JVM...
INFO   | jvm 1    | 2004/06/15 08:12:47 | Wrapper (Version 3.1.0)
http://wrapper.tanukisoftware.org
INFO   | jvm 1    | 2004/06/15 08:12:47 | 
STATUS | wrapper  | 2004/06/15 08:17:26 | CTRL-C trapped.  Shutting
down.
INFO   | jvm 1    | 2004/06/15 08:17:26 | The Stop Method Got Called.
INFO   | jvm 1    | 2004/06/15 08:17:26 | Calling pauseServer
INFO   | jvm 1    | 2004/06/15 08:17:26 | Error in WrapperListener.stop
callback.  java.lang.NullPointerException
INFO   | jvm 1    | 2004/06/15 08:17:26 |
java.lang.NullPointerExceptionisControlledByNativeWrapper
INFO   | jvm 1    | 2004/06/15 08:17:26 | 
INFO   | jvm 1    | 2004/06/15 08:17:26 |  at
com.lmco.itis.fis.server.ApplicationMain.stopServer(ApplicationMain.java
:26)
INFO   | jvm 1    | 2004/06/15 08:17:26 |  at
MainWrapper.stop(MainWrapper.java:61)
INFO   | jvm 1    | 2004/06/15 08:17:26 |  at
org.tanukisoftware.wrapper.WrapperManager.stopInner(WrapperManager.java:
1903)
INFO   | jvm 1    | 2004/06/15 08:17:26 |  at
org.tanukisoftware.wrapper.WrapperManager.handleSocket(WrapperManager.ja
va:2312)
INFO   | jvm 1    | 2004/06/15 08:17:26 |  at
org.tanukisoftware.wrapper.WrapperManager.run(WrapperManager.java:2602)
INFO   | jvm 1    | 2004/06/15 08:17:26 |  at
java.lang.Thread.run(Thread.java:536)
STATUS | wrapper  | 2004/06/15 08:17:27 | <-- Wrapper Stopped
 
 
 
 
     C O N S O L E
------------------------------------------------------------------------
------------------------------------------------------
wrapper  | --> Wrapper Started as Console
wrapper  | Launching a JVM...
jvm 1    | Wrapper (Version 3.1.0) http://wrapper.tanukisoftware.org
jvm 1    |
wrapper  | CTRL-C trapped.  Shutting down.
jvm 1    | The Stop Method Got Called.
jvm 1    | Calling pauseServer
jvm 1    | Error in WrapperListener.stop callback.
java.lang.NullPointerException
jvm 1    | java.lang.NullPointerExceptionisControlledByNativeWrapper
jvm 1    |
jvm 1    |      at
com.lmco.itis.fis.server.ApplicationMain.stopServer(ApplicationMain.java
:26)
jvm 1    |      at MainWrapper.stop(MainWrapper.java:61)
jvm 1    |      at
org.tanukisoftware.wrapper.WrapperManager.stopInner(WrapperManager.java:
1903)
jvm 1    |      at
org.tanukisoftware.wrapper.WrapperManager.handleSocket(WrapperManager.ja
va:2312)
jvm 1    |      at
org.tanukisoftware.wrapper.WrapperManager.run(WrapperManager.java:2602)
jvm 1    |      at java.lang.Thread.run(Thread.java:536)
wrapper  | <-- Wrapper Stopped
Terminate batch job (Y/N)?

Re: [Wrapper-user] RE: JVM exit - no log error entries

[Paul C. <cas...@au...>]

Leif,

Yep, Win2K Advanced Server / JDK 1.3.1_11.

Doing some more testing on it tonight to get some more info about whether
it's the particular printer driver / the scaling at which the map object is
being plotted etc.

Got me baffled.

Regards,

Paul Casanova



|---------+---------------------------------------->
|         |           Leif Mortenson               |
|         |           <le...@ta...>    |
|         |           Sent by:                     |
|         |           wra...@li...|
|         |           ceforge.net                  |
|         |                                        |
|         |                                        |
|         |           11/06/2004 03:06 PM          |
|         |           Please respond to            |
|         |           wrapper-user                 |
|---------+---------------------------------------->
  >--------------------------------------------------------------------------------------------------------------|
  |                                                                                                              |
  |       To:       wra...@li...                                                           |
  |       cc:                                                                                                    |
  |       Subject:  Re: [Wrapper-user] RE: JVM exit - no log error entries                                       |
  >--------------------------------------------------------------------------------------------------------------|




Paul,
    I need to get caught up on mail...

    I looked in the MSVC docs and found that the error code 128 is
ERROR_WAIT_NO_CHILDREN, which has the description
"There are no child processes to wait for."

    When the Wrapper has decided that the JVM process is gone, the
Wrapper makes a call to get that process's exit code which is being
returned as 128 in your case.   That might make sense if that process
at died abnormally and simply went away...   From the log info there
is not really any useful information about what might have happened
to it however.

    If I kill the process with the task manager, I am getting an exit code
of 1.   But in that case, the system is still bringing the process down
reasonably cleanly.

    What platform are you using?  I am assuming Windows at the moment.

Cheers,
Leif

128          There are no child processes to wait for.
ERROR_WAIT_NO_CHILDREN


Paul Casanova wrote:

>
>
>Hi again.
>
>I'm now able to replicate this JVM exit consistently, so I turned on
debug.
>However, I only got 1 more line of logging:
>
>DEBUG  | wrapper  | 2004/06/11 08:46:07 | Got ping response from JVM
>INFO   | jvm 1    | 2004/06/11 08:46:09 |
>DEBUG  | wrapper  | 2004/06/11 08:46:09 | JVM process exited with a code
of
>128, setting the wrapper exit code to 128.
>ERROR  | wrapper  | 2004/06/11 08:46:09 | JVM exited unexpectedly.
>DEBUG  | wrapper  | 2004/06/11 08:46:09 | Waiting 5 seconds before
>launching another JVM.
>STATUS | wrapper  | 2004/06/11 08:46:13 | Launching a JVM...
>
>I've done a search in the Java forums and on the web, but can't find any
>info on the exit code 128 for the JVM.
>
>Has anyone seen something like this before, or does any have any other
>ideas / suggestions?
>
>Regards,
>
>Paul Casanova
>
>
>
>Hi all,
>
>Our application crashed this morning after a user attempted a print using
a
>Lexmark Optra Color 45 driver.  We haven't had an issue with this driver
>before, so it has me baffled.
>
>Here's a timeline of the facts that I can gather:
>9:38:05     A blank line was logged by the Java Service Wrapper. This
>suggests that an error was thrown by the JVM, but it didn't get to log it
>because:
>9:38:06     The JVM exited without any error information.
>9:38:06     The Windows Event Log shows the Lexmark Optra Color 45
>completing a print process (ie generating a plot file) - although the
>resultant file was 0 bytes in length.
>
>A PrinterException should have been thrown by the printing process, but it
>shouldn't have made the JVM crash.
>
>We're using 1.3.1_11.
>
>Here's the output of the JSW log file at that time:
>
>INFO   | jvm 1    | 2004/06/09 09:38:05 |
>ERROR  | wrapper  | 2004/06/09 09:38:06 | JVM exited unexpectedly.
>STATUS | wrapper  | 2004/06/09 09:38:10 | Launching a JVM...
>INFO   | jvm 2    | 2004/06/09 09:38:10 | Wrapper (Version 3.1.0)
>http://wrapper.tanukisoftware.org
>INFO   | jvm 2    | 2004/06/09 09:38:10 |
>
>Why the blank lines?
>
>There had been no activity between 9.34 and 9.38am, so the info above this
>in the log file is not relevant.
>
>I thought I had the JSW configured to dump out thread stuff on exit.
>Here's my conf details:
>
># Request a thread dump on JVM exit
>wrapper.request_thread_dump_on_failed_jvm_exit=true
>
>#********************************************************************
># Wrapper Logging Properties
>#********************************************************************
>wrapper.console.format=LPTM
>wrapper.console.loglevel=INFO
>wrapper.logfile=%RCIS_HOME%\Service\logs\RCISMainServer.log
>wrapper.logfile.format=LPTM
>wrapper.logfile.loglevel=INFO
>wrapper.logfile.maxsize=1m
>wrapper.logfile.maxfiles=100
>wrapper.syslog.loglevel=ERROR
>
># Allow the service to interact with the desktop.
>wrapper.ntservice.interactive=false
>
># Disable the wrapper startup timeout facility
>wrapper.startup.timeout=0
>
># Enable the wrapper exit timeout facility so that the JVM will be
>terminated if shutdown fails
>wrapper.jvm_exit.timeout=120
>
># Enable the wrapper shutdown timeout facility so that the JVM will be
>terminated if shutdown fails
>wrapper.shutdown.timeout=120
>
># Extend the wrapper ping timeout facility to prevent restarting under
>normal operation (10 minutes)
>wrapper.ping.timeout=300
>
>Does this all look reasonable?  I'd rather not have debug on all the time
>if we can get away with it - a problem like this might not occur for
>another few months, but I'd like to be able to explain it to the client
>when and if it does.
>
>Any ideas would be greatly appreciated.
>
>Regards,
>
>Paul Casanova
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by the new InstallShield X.
>>From Windows to Linux, servers to mobile, InstallShield X is the
>one installation-authoring solution that does it all. Learn more and
>evaluate today! http://www.installshield.com/Dev2Dev/0504
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...
>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>
>



-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the
one installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] RE: JVM exit - no log error entries

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

Paul,
    I need to get caught up on mail...

    I looked in the MSVC docs and found that the error code 128 is
ERROR_WAIT_NO_CHILDREN, which has the description
"There are no child processes to wait for."

    When the Wrapper has decided that the JVM process is gone, the
Wrapper makes a call to get that process's exit code which is being
returned as 128 in your case.   That might make sense if that process
at died abnormally and simply went away...   From the log info there
is not really any useful information about what might have happened
to it however.

    If I kill the process with the task manager, I am getting an exit code
of 1.   But in that case, the system is still bringing the process down
reasonably cleanly. 

    What platform are you using?  I am assuming Windows at the moment.

Cheers,
Leif

128 	There are no child processes to wait for. 	ERROR_WAIT_NO_CHILDREN


Paul Casanova wrote:

>
>
>Hi again.
>
>I'm now able to replicate this JVM exit consistently, so I turned on debug.
>However, I only got 1 more line of logging:
>
>DEBUG  | wrapper  | 2004/06/11 08:46:07 | Got ping response from JVM
>INFO   | jvm 1    | 2004/06/11 08:46:09 |
>DEBUG  | wrapper  | 2004/06/11 08:46:09 | JVM process exited with a code of
>128, setting the wrapper exit code to 128.
>ERROR  | wrapper  | 2004/06/11 08:46:09 | JVM exited unexpectedly.
>DEBUG  | wrapper  | 2004/06/11 08:46:09 | Waiting 5 seconds before
>launching another JVM.
>STATUS | wrapper  | 2004/06/11 08:46:13 | Launching a JVM...
>
>I've done a search in the Java forums and on the web, but can't find any
>info on the exit code 128 for the JVM.
>
>Has anyone seen something like this before, or does any have any other
>ideas / suggestions?
>
>Regards,
>
>Paul Casanova
>
>
>
>Hi all,
>
>Our application crashed this morning after a user attempted a print using a
>Lexmark Optra Color 45 driver.  We haven't had an issue with this driver
>before, so it has me baffled.
>
>Here's a timeline of the facts that I can gather:
>9:38:05     A blank line was logged by the Java Service Wrapper. This
>suggests that an error was thrown by the JVM, but it didn't get to log it
>because:
>9:38:06     The JVM exited without any error information.
>9:38:06     The Windows Event Log shows the Lexmark Optra Color 45
>completing a print process (ie generating a plot file) - although the
>resultant file was 0 bytes in length.
>
>A PrinterException should have been thrown by the printing process, but it
>shouldn't have made the JVM crash.
>
>We're using 1.3.1_11.
>
>Here's the output of the JSW log file at that time:
>
>INFO   | jvm 1    | 2004/06/09 09:38:05 |
>ERROR  | wrapper  | 2004/06/09 09:38:06 | JVM exited unexpectedly.
>STATUS | wrapper  | 2004/06/09 09:38:10 | Launching a JVM...
>INFO   | jvm 2    | 2004/06/09 09:38:10 | Wrapper (Version 3.1.0)
>http://wrapper.tanukisoftware.org
>INFO   | jvm 2    | 2004/06/09 09:38:10 |
>
>Why the blank lines?
>
>There had been no activity between 9.34 and 9.38am, so the info above this
>in the log file is not relevant.
>
>I thought I had the JSW configured to dump out thread stuff on exit.
>Here's my conf details:
>
># Request a thread dump on JVM exit
>wrapper.request_thread_dump_on_failed_jvm_exit=true
>
>#********************************************************************
># Wrapper Logging Properties
>#********************************************************************
>wrapper.console.format=LPTM
>wrapper.console.loglevel=INFO
>wrapper.logfile=%RCIS_HOME%\Service\logs\RCISMainServer.log
>wrapper.logfile.format=LPTM
>wrapper.logfile.loglevel=INFO
>wrapper.logfile.maxsize=1m
>wrapper.logfile.maxfiles=100
>wrapper.syslog.loglevel=ERROR
>
># Allow the service to interact with the desktop.
>wrapper.ntservice.interactive=false
>
># Disable the wrapper startup timeout facility
>wrapper.startup.timeout=0
>
># Enable the wrapper exit timeout facility so that the JVM will be
>terminated if shutdown fails
>wrapper.jvm_exit.timeout=120
>
># Enable the wrapper shutdown timeout facility so that the JVM will be
>terminated if shutdown fails
>wrapper.shutdown.timeout=120
>
># Extend the wrapper ping timeout facility to prevent restarting under
>normal operation (10 minutes)
>wrapper.ping.timeout=300
>
>Does this all look reasonable?  I'd rather not have debug on all the time
>if we can get away with it - a problem like this might not occur for
>another few months, but I'd like to be able to explain it to the client
>when and if it does.
>
>Any ideas would be greatly appreciated.
>
>Regards,
>
>Paul Casanova
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by the new InstallShield X.
>>From Windows to Linux, servers to mobile, InstallShield X is the
>one installation-authoring solution that does it all. Learn more and
>evaluate today! http://www.installshield.com/Dev2Dev/0504
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...
>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>  
>

[Wrapper-user] RE: JVM exit - no log error entries

[Paul C. <cas...@au...>]

Hi again.

I'm now able to replicate this JVM exit consistently, so I turned on debug.
However, I only got 1 more line of logging:

DEBUG  | wrapper  | 2004/06/11 08:46:07 | Got ping response from JVM
INFO   | jvm 1    | 2004/06/11 08:46:09 |
DEBUG  | wrapper  | 2004/06/11 08:46:09 | JVM process exited with a code of
128, setting the wrapper exit code to 128.
ERROR  | wrapper  | 2004/06/11 08:46:09 | JVM exited unexpectedly.
DEBUG  | wrapper  | 2004/06/11 08:46:09 | Waiting 5 seconds before
launching another JVM.
STATUS | wrapper  | 2004/06/11 08:46:13 | Launching a JVM...

I've done a search in the Java forums and on the web, but can't find any
info on the exit code 128 for the JVM.

Has anyone seen something like this before, or does any have any other
ideas / suggestions?

Regards,

Paul Casanova



Hi all,

Our application crashed this morning after a user attempted a print using a
Lexmark Optra Color 45 driver.  We haven't had an issue with this driver
before, so it has me baffled.

Here's a timeline of the facts that I can gather:
9:38:05     A blank line was logged by the Java Service Wrapper. This
suggests that an error was thrown by the JVM, but it didn't get to log it
because:
9:38:06     The JVM exited without any error information.
9:38:06     The Windows Event Log shows the Lexmark Optra Color 45
completing a print process (ie generating a plot file) - although the
resultant file was 0 bytes in length.

A PrinterException should have been thrown by the printing process, but it
shouldn't have made the JVM crash.

We're using 1.3.1_11.

Here's the output of the JSW log file at that time:

INFO   | jvm 1    | 2004/06/09 09:38:05 |
ERROR  | wrapper  | 2004/06/09 09:38:06 | JVM exited unexpectedly.
STATUS | wrapper  | 2004/06/09 09:38:10 | Launching a JVM...
INFO   | jvm 2    | 2004/06/09 09:38:10 | Wrapper (Version 3.1.0)
http://wrapper.tanukisoftware.org
INFO   | jvm 2    | 2004/06/09 09:38:10 |

Why the blank lines?

There had been no activity between 9.34 and 9.38am, so the info above this
in the log file is not relevant.

I thought I had the JSW configured to dump out thread stuff on exit.
Here's my conf details:

# Request a thread dump on JVM exit
wrapper.request_thread_dump_on_failed_jvm_exit=true

#********************************************************************
# Wrapper Logging Properties
#********************************************************************
wrapper.console.format=LPTM
wrapper.console.loglevel=INFO
wrapper.logfile=%RCIS_HOME%\Service\logs\RCISMainServer.log
wrapper.logfile.format=LPTM
wrapper.logfile.loglevel=INFO
wrapper.logfile.maxsize=1m
wrapper.logfile.maxfiles=100
wrapper.syslog.loglevel=ERROR

# Allow the service to interact with the desktop.
wrapper.ntservice.interactive=false

# Disable the wrapper startup timeout facility
wrapper.startup.timeout=0

# Enable the wrapper exit timeout facility so that the JVM will be
terminated if shutdown fails
wrapper.jvm_exit.timeout=120

# Enable the wrapper shutdown timeout facility so that the JVM will be
terminated if shutdown fails
wrapper.shutdown.timeout=120

# Extend the wrapper ping timeout facility to prevent restarting under
normal operation (10 minutes)
wrapper.ping.timeout=300

Does this all look reasonable?  I'd rather not have debug on all the time
if we can get away with it - a problem like this might not occur for
another few months, but I'd like to be able to explain it to the client
when and if it does.

Any ideas would be greatly appreciated.

Regards,

Paul Casanova

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

[Jeremy Fujimoto-J. <coe...@us...>]

Have you checked in the services control panel to see if the Startup Type =
is set to Manual or Automatic?=20
When you install the service (using the batch file provided with JavaServic=
eWrapper) the Startup Type should be set to Automatic if wrapper.ntservice.=
starttype=3DAUTO_START is in the wrapper.conf file. However, you can =
change the Startup Type yourself in the Services Control panel and it will =
obey how you set it (not how it's set in the wrapper.conf file).=20
I would still recommend having the value in the wrapper.conf file match =
what you want it to be in case you decide to uninstall and reinstall the =
service later on.

-Jeremy Fujimoto-Johnson
Sr. Programmer/Analyst - eTechnology
Adventist Health

>>> ste...@sr... 6/10/04 12:52:58 PM >>>


I am using the wrapper, on NT 2000, and it seems to be working just fine, =
except for one thing.=20

Even though the parameter is set to AUTO_START, when I install the =
service, or reboot the machine, the service does not start.  I can start =
it manually, and it works fine.=20

Does anyone have any ideas as to why this is happening, or how I can fix =
it.  I would rather it start when the machine was booted.=20

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

[Wrapper-user] Wrapper Service not automatically starting on NT

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

I am using the wrapper, on NT 2000, and it seems to be working just fine, 
except for one thing.

Even though the parameter is set to AUTO_START, when I install the 
service, or reboot the machine, the service does not start.  I can start 
it manually, and it works fine.

Does anyone have any ideas as to why this is happening, or how I can fix 
it.  I would rather it start when the machine was booted.

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