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

Re: [Wrapper-user] Log4J problem.

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

I use log4j and the wrapper logging togther.
You need to have atleast INFO level logging enabled in the wrapper 
config file to get messages from the inner wrapped application.
I have used the SysLog, Console and RollingFile appenders w/ no issues.

You should see in effect duplicate logging- logging specified in the 
wrapper conf file and any logging you specify in the log4j.xml file.

Jennifer
On Jun 21, 2004, at 9:35 PM, Leif Mortenson wrote:

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

[Wrapper-user] Re: Notification when Wrapper restarts JVM / JMX / Winodws-Services

[Daniel S. <jav...@da...>]

Hi

Is there a possibility to get a notification (besides the log) or to 
start an other application if the Service-wrapper restarts the JVM 
because of a crash? (my only idea was to scan the log for restarts)

Another Idea was to use JMX; but how does this work if the service is 
already running? I can use JMX to start the wrapper, but the wrapper is 
alredy running (as Windows service) and I would like to connect afterwards.

other question:
I declared a dependent service. I would appreciate it now, that the 
dependent service restarts, if the JVM of the 'mother-service' crashes 
and restarts. any possibilities?

and why isn't it possible that windows restarts the wrapper-service if 
it crashes (or execute one of the other windows-serivce options, when 
the service fails)

best regards
Daniel

Re: [Wrapper-user] XML output for logging

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

Richard,
I think I just answered your feature request on this subject as well.

It is possible to use log4j inside of the JVM to redirect all of your 
application's output
to whatever target you wish. The Wrapper implements its own logging 
system. While
it is possible to use it to log all console output from the JVM, it is 
really meant to be
used for logging of the Wrapper application. It is not possible to 
redirect this output
to another logging system because much of the output is generated 
outside of the
JVM. Piping the output back into the JVM would not work because the JVM is
not always running when output needs to be logged.

Cheers,
Leif

Michaud, Richard1 wrote:

> Does anyone know the facility wrapper uses for its logging?. I have a 
> service (under Windows 2000) running that outputs its logs using 
> log4j. It uses the console appender so that the logs get added to the 
> wrapper log. This works well, but I’d like to see if its feasible to 
> get the logs output in XML format for review by the the log4j Chainsaw 
> tool.
>

[Wrapper-user] XML output for logging

[Michaud, R. <ric...@ci...>]

Does anyone know the facility wrapper uses for its logging?.  I have a
service (under Windows 2000) running that outputs its logs using log4j.
It uses the console appender so that the logs get added to the wrapper
log.  This works well, but I'd like to see if its feasible to get the
logs output in XML format for review by the the log4j Chainsaw tool.

=20

=20

RE: [Wrapper-user] Should my application block?

[Keith <li...@ke...>]

Spot-on Leif, that was my problem.

Thanks also to Randy for his suggestion.

Cheers for the help, everything is working great now!! Very useful utility!

Keith.

-----Original Message-----
From: wra...@li...
[mailto:wra...@li...]On Behalf Of Leif Mortenson
Sent: 08 July 2004 04:24
To: wra...@li...
Subject: Re: [Wrapper-user] Should my application block?

Keith,
Integration Methods 1 and 2 (WrapperSimpleApp and WrapperStartStopApp)
both handle the case where the main method does not return correctly.
Method #3
expects that the WrapperListener.start method always returns.

If as you say you are using Method 1, then it should not matter whether
or not your
main method has blocking code in it.

Sorry if I am wrong, but here is my guess. What did you specify for your
main
class? Method #1 expects that this is always o.t.w.WrapperSimpleApp. The
main
class of your application is then specified as the first parameter to
the helper class's
main method. My guess is that you are probably specifying your main
class directly.
If you are using version 3.1.0 then the wrapper.log should contain a message
informing you of this mistake.

As a note with the Wrapper you should always test the integration running in
a console before you attempt to run it as a service. It is much easier
to debug that
way as the messages are all in the console.

If you are still not able to gt things working then I will need to see your
wrapper.conf and a your wrapper.log file containing a single JVM run
with the
wrapper.debug=true property set.

Cheers,
Leif

Keith wrote:

>Hi All,
>
>Great util, but I'm having a problem getting it set up. I've followed the
>instructions for integration method1, and launching the myApp.bat file will
>launch my App, which acts as a listener on a TCP port.
>
>Should my application block once this listener thread has been set up? If I
>do, I get an error starting the service (after a short while), as it stays
>in my main method and never exits. If I remove the infinite loop from the
>end, it falls straight through when starting the service, with a "your
>service has started then stopped; some services automatically" message from
>the OS.
>
>Any thoughts? Am I missing something that I should be doing to inform the
>wrapper that my service is up and running? When I block, the service is
>running, but you get the "service did not respond in a timely fashion"
error
>dialog. Once this happens, it's no longer running... :-(  If I don't block,
it
>only lasts for a second.
>
>Thanks in advance!
>
>Keith.
>
>



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


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

Re: [Wrapper-user] Should my application block?

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

Keith,
Integration Methods 1 and 2 (WrapperSimpleApp and WrapperStartStopApp)
both handle the case where the main method does not return correctly. 
Method #3
expects that the WrapperListener.start method always returns.

If as you say you are using Method 1, then it should not matter whether 
or not your
main method has blocking code in it.

Sorry if I am wrong, but here is my guess. What did you specify for your 
main
class? Method #1 expects that this is always o.t.w.WrapperSimpleApp. The 
main
class of your application is then specified as the first parameter to 
the helper class's
main method. My guess is that you are probably specifying your main 
class directly.
If you are using version 3.1.0 then the wrapper.log should contain a message
informing you of this mistake.

As a note with the Wrapper you should always test the integration running in
a console before you attempt to run it as a service. It is much easier 
to debug that
way as the messages are all in the console.

If you are still not able to gt things working then I will need to see your
wrapper.conf and a your wrapper.log file containing a single JVM run 
with the
wrapper.debug=true property set.

Cheers,
Leif

Keith wrote:

>Hi All,
>
>Great util, but I’m having a problem getting it set up. I’ve followed the
>instructions for integration method1, and launching the myApp.bat file will
>launch my App, which acts as a listener on a TCP port.
>
>Should my application block once this listener thread has been set up? If I
>do, I get an error starting the service (after a short while), as it stays
>in my main method and never exits. If I remove the infinite loop from the
>end, it falls straight through when starting the service, with a “your
>service has started then stopped; some services automatically” message from
>the OS.
>
>Any thoughts? Am I missing something that I should be doing to inform the
>wrapper that my service is up and running? When I block, the service is
>running, but you get the “service did not respond in a timely fashion” error
>dialog. Once this happens, it’s no longer running… :-(  If I don’t block, it
>only lasts for a second.
>
>Thanks in advance!
>
>Keith.
>  
>

Re: [Wrapper-user] Console Not Presented

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

Richard,
Not having used CruiseControl, I am not sure what you are referring to when
you say "console"? Is this a text console, or a swing base GUI?

The Wrapper can be run in console mode or as a service. What happens
when you are running in console mode on both platforms? Are you able to
see your "console"? If not then the rest of this mail will not make any
difference.

On Windows when running as a service, you must set the
wrapper.ntservice.interactive property to true or the Service will not be
able to present any kind of a UI to the user. If your "console" is Swing
based then this will make it visible.
http://wrapper.tanukisoftware.org/doc/english/prop-ntservice-interactive.html

If however you wish to display the text based console of the Wrapper and
thus JVM, you will also need to set the wrapper.ntservice.console
property to TRUE:
http://wrapper.tanukisoftware.org/doc/english/prop-ntservice-console.html

On Linux, if your application wishes to display a GUI, then Java must be
able
to access the DISPLAY environment variable. You will need to make sure
that the Wrapper is launched in an environment where that is set. If you
have configured your system to start the wrapper on system startup then
the DISPLAY variable will not be set at that point.

There are some games that you can play by setting it manually in the
wrapper.conf file and then doing occasional JVM restarts if the JVM is
having problems displaying its GUI. Once the window system is up and a
user has logged in the display will become available and the program should
be able to show its interface. (This is untried, but it should work...)

Cheers,
Leif


Neale, Richard wrote:

> Hello,
> I have created a CruiseControl (http://cruisecontrol.sourceforge.net/)
> wrapper
> and I appear to have things running on NT and Linux but I do not see
> the console
> on either.
> To note: CruiseControl has a JMX Console and I have tried with and
> without.
> Thoughts ?
> Rich
>

Re: [Wrapper-user] Application Exception handling:How to do it

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

Venkatesh,
    I agree that littering your code with Wrapper references is not a 
very good idea.
The Wrapper does provide you with a few ways of avoiding this however.

1) Create a shutdown method which centralizes the WrapperManager.restart 
code
to a single location.  (Not much better but it does allow you to make 
your code
cleaner)

2) Register Output triggers with the Wrapper. (v3.0.0 and above)
If your application reliably outputs a message to the console then the 
Wrapper
is able to trigger on that output and shutdown or restart the JVM.   See the
following for details:

http://wrapper.tanukisoftware.org/doc/english/prop-filter-x-n.html

3) Register on-exit events with the Wrapper. (v3.1.0 and above)
The Wrapper is capable of performing different actions depending on the exit
code returned when the JVM exits.   You could for example trigger a restart
if the JVM exits with a non-zero exit code.   See the following for details:

http://wrapper.tanukisoftware.org/doc/english/prop-on-exit-n.html

wrapper.on_exit.default=RESTART
wrapper.on_exit.0=SHUTDOWN

Whenever a fatal error is encountered, simply call System.exit(1) and your
JVM will be restarted by the Wrapper.   About as non-intrusive as you 
can get.

Cheers,
Leif

Venkatesh Sellappa wrote:

>Hi All,
>
>My problem,
>
>I have an application that is dependent on multiple resources and there is no single entry point/catch-all
>class where i can monitor the resources.
>I understand that the standard way of handling runtime crashes is to 
>
>try
>{
> // do something
>}
>catch ( Exception x )
>{
> // clear stacks
> WrapperManager.restart();
>}
>This would allow us to restart the JVM.
>My quibble, this is a fairly intrusive way of doing things, as the classes now become
>WrapperManager dependent.
>
>Has anyone found any other way of doing this ?
>
>I am using Integration method 3.
>Any and all suggestions welcome.
>
>Rgds,
>  
>

Re: [Wrapper-user] Should my application block?

[Randy M. <mu...@ca...>]

I would suggest you place your blocking read in a separate thread and
run() it from your main() method. =20

Randy

On Wed, 2004-07-07 at 11:01, Keith wrote:
> Hi All,
>=20
> Great util, but I=C2=92m having a problem getting it set up. I=C2=92ve fo=
llowed the
> instructions for integration method1, and launching the myApp.bat file wi=
ll
> launch my App, which acts as a listener on a TCP port.
>=20
> Should my application block once this listener thread has been set up? If=
 I
> do, I get an error starting the service (after a short while), as it stay=
s
> in my main method and never exits. If I remove the infinite loop from the
> end, it falls straight through when starting the service, with a =C2=93yo=
ur
> service has started then stopped; some services automatically=C2=94 messa=
ge from
> the OS.
>=20
> Any thoughts? Am I missing something that I should be doing to inform the
> wrapper that my service is up and running? When I block, the service is
> running, but you get the =C2=93service did not respond in a timely fashio=
n=C2=94 error
> dialog. Once this happens, it=C2=92s no longer running=C2=85 :-(  If I do=
n=C2=92t block, it
> only lasts for a second.
>=20
> Thanks in advance!
>=20
> Keith.
>=20
>=20
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20
> digital self defense, top technical experts, no vendor pitches,=20
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
--=20
Randy Murrish
Cassatt Corporation

[Wrapper-user] Should my application block?

[Keith <li...@ke...>]

Hi All,

Great util, but I’m having a problem getting it set up. I’ve followed the
instructions for integration method1, and launching the myApp.bat file will
launch my App, which acts as a listener on a TCP port.

Should my application block once this listener thread has been set up? If I
do, I get an error starting the service (after a short while), as it stays
in my main method and never exits. If I remove the infinite loop from the
end, it falls straight through when starting the service, with a “your
service has started then stopped; some services automatically” message from
the OS.

Any thoughts? Am I missing something that I should be doing to inform the
wrapper that my service is up and running? When I block, the service is
running, but you get the “service did not respond in a timely fashion” error
dialog. Once this happens, it’s no longer running… :-(  If I don’t block, it
only lasts for a second.

Thanks in advance!

Keith.


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

Re: [Wrapper-user] Need ability to become different user on wrapper launch

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

Rich,
Thanks. I went ahead and implemented this for the 3.1.1 release. I have
attached the new template sh script. If anyone has any comments on it I
would appreciate hearing them before the release.

I did did things a bit differently that the script you sent me. Unless I
am missing something, I don't think that there is any reason to change the
use user when stopping the Wrapper or requesting a dump. If the user
calling the script has the ability to call su, then they will also have the
ability to call kill. Setting the user also causes problems when not running
as root as it will prompt the user for a password even though the user may
already have the privileges necessary to kill the process.

This script tests the current user even when running the 'start' command
and only uses su if the user would change. This is to avoid a problem where
the user will be prompted for a password even when using su to run as
themselves.

You had mentioned path problems. I think they were being caused by
your use of 'su - user -c "cmd"' to launch the Wrapper. That option
causes the new cmd to be run in that user's home directory. You can see
this by running 'su - user -c "pwd"'.

Instread I am using 'su -m user -c "cmd"'. This way the current
environment is maintained when running the Wrapper. I could see where
this would have drawbacks as well, so it is up to you which one you would
rather use. I am leaning toward the later behavior for the default script
however.

Thanks for the patch, I can actually use this myself, just never got
around to writing those few little lines :-)

Cheers,
Leif

Neale, Richard wrote:

> Feature Suggestion:
> Provide the hooks / example to 'su' to a new user in unix launch of
> wrapper.
> Typically in a unix boot the user is root, however, many times you need to
> be a different user when launching services. To do this, you use 'su'
> in the
> init.d scripts to become that user.
> I have hacked together the elements to do this in the two files;
> wrapper.conf and testwrapper
> testwrapper is the attached cruisecontrol
> wrapper.conf (not attached) required full path definitions which were
> easily to discern, however,
> I thought exported envvars would be expanded from cruisecontrol
> (testwrapper). Must be doing
> something wrong here so I have left the full paths in. Maybe the su
> masked.
> Also note what I did to the kills.
> Thoughts ?
> Rich

[Wrapper-user] Application Exception handling:How to do it

[Venkatesh S. <Ven...@lc...>]

++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Please read the disclaimer at the bottom of this e-mail.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Hi All,

My problem,

I have an application that is dependent on multiple resources and there is =
no single entry point/catch-all
class where i can monitor the resources.
I understand that the standard way of handling runtime crashes is to=20

try
{
 // do something
}
catch ( Exception x )
{
 // clear stacks
 WrapperManager.restart();
}
This would allow us to restart the JVM.
My quibble, this is a fairly intrusive way of doing things, as the classes =
now become
WrapperManager dependent.

Has anyone found any other way of doing this ?

I am using Integration method 3.
Any and all suggestions welcome.

Rgds,


**********************************************************************
This email is intended for the named recipient(s) only. Its contents
are  confidential and may only be retained by the named recipient(s)
and may only be copied or  disclosed  with the consent of=20
LCH.Clearnet Limited.   If you are not an intended recipient please
delete this e-mail and notify pos...@lc....

The contents  of this  email are  subject to  contract in all cases,=20
and LCH.Clearnet Limited makes no contractual commitment save where
confirmed by hard copy.  LCH.Clearnet Limited accepts no liability,=20
including liability for negligence, in respect of any statement in=20
this email.

LCH.Clearnet Limited, Registered Office: Aldgate House,=20
33 Aldgate High Street, London EC3N 1EA.    Recognised as a Clearing=20
House under the Financial Services & Markets Act 2000. Reg in England No.25=
932=20
Telephone: +44 20 7426 7000              Internet: http://www.lchclearnet.c=
om
**********************************************************************

Re: [Wrapper-user] OutOfMemoryError

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

Nick,
    It looks like the thread which is running your main method did 
something that
caused an OutOfMemoryError.   Unfortunately, when this happens a stack trace
is not usually available.  This is because at that point the JVM does 
not have
enough memory to create one.
    Your code is not catching the exception so it is being thrown all 
the way back
up until the low level Wrapper code catches it and shuts down the JVM.   
If you
do not like this behavior then you can place a try { } catch (Throwable 
t) { log }
in your main method.  This only happens if your main method called by the
Wrapper code throws the exception.   Most servers don't actually run in this
thread.

    In the case of OutOfMemoryErrors, this is going to be a problem in your
application however.   Java is much better about memory leaks than C or 
other
languages, but if you keep placing objects into a list without pulling 
them out
for example then you will run into this problem.
    It is also possible that your application simply needs more memory than
the default 64MB.   If so, you can increase the max memory in the
wrapper.conf file.   Make sure that you don't set it to more memory than is
available on the system however as Java gets VERY SLOW when it is
forced to do lots of disk swapping.

    Is this maybe related to that other problem where your application 
shutdown
when you deleted the log files?

Cheers,
Leif

Nick Rice wrote:

>The wrapper service was up running for a few hours and then it abruptly
>stopped with the following log dump:
>
>
>INFO   | jvm 1    | 2004/07/03 12:15:16 | WrapperSimpleApp: Encountered
>an error running main: java.lang.OutOfMemoryError
>INFO   | jvm 1    | 2004/07/03 12:15:16 | java.lang.OutOfMemoryError
>INFO   | jvm 1    | 2004/07/03 12:15:16 | WrapperManager.stop(1) called
>by thread: WrapperSimpleAppMain
>INFO   | jvm 1    | 2004/07/03 12:15:16 | Send a packet STOP : 1
>DEBUG  | wrapperp | 2004/07/03 12:15:16 | read a packet STOP : 1
>DEBUG  | wrapper  | 2004/07/03 12:15:16 | JVM requested a shutdown. (1)
>DEBUG  | wrapper  | 2004/07/03 12:15:16 | wrapperStopProcess(1) called.
>DEBUG  | wrapper  | 2004/07/03 12:15:16 | Sending stop signal to JVM
>DEBUG  | wrapperp | 2004/07/03 12:15:16 | send a packet STOP : NULL
>INFO   | jvm 1    | 2004/07/03 12:15:16 | Received a packet STOP :
>INFO   | jvm 1    | 2004/07/03 12:15:17 | Thread, WrapperSimpleAppMain,
>handling the shutdown process.
>INFO   | jvm 1    | 2004/07/03 12:15:17 | calling listener.stop()
>INFO   | jvm 1    | 2004/07/03 12:15:17 | WrapperSimpleApp: stop(1)
>INFO   | jvm 1    | 2004/07/03 12:15:17 | returned from listener.stop()
>INFO   | jvm 1    | 2004/07/03 12:15:17 | Send a packet STOPPED : 0
>DEBUG  | wrapperp | 2004/07/03 12:15:17 | read a packet STOPPED : 0
>DEBUG  | wrapper  | 2004/07/03 12:15:17 | JVM signalled that it was
>stopped.
>INFO   | jvm 1    | 2004/07/03 12:15:17 | Closing socket.
>DEBUG  | wrapperp | 2004/07/03 12:15:17 | socket read no code (closed?).
>INFO   | jvm 1    | 2004/07/03 12:15:18 | calling System.exit(1)
>INFO   | jvm 1    | 2004/07/03 12:15:18 | Server daemon shut down
>DEBUG  | wrapper  | 2004/07/03 12:15:21 | JVM process exited with a code
>of 1, however the wrapper exit code was already 1.
>DEBUG  | wrapper  | 2004/07/03 12:15:21 | JVM exited normally.
>
>
>Any clues?
>  
>

Re: [Wrapper-user] Re: Newbie - App Integration

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

Nick,

>Thanks for your assistance Leif. The instructions helped me setup the
>wrapper and get it to work. Its working fine now.
>
Great glad you got things working.

> Once small issue I
>came across was that if I manually deleted all the logs while the
>wrapper service was running (as a daemon on Linux in this case), the
>service would somehow stop on its own.
>  
>
I just reverified this on a Linux machine and it appears to be working 
for me.  You
should be able to delete the wrapper.log file at any time without 
causing any
problems.   Exactly what file are you deleting?  Even if there was an 
error of some
kind which caused the Wrapper to shutdown, it should be recreating the 
wrapper.log
as it writes out messages as it shuts down.

Do you have any other log files that are created by your Java 
application.  Deleting
one of those could cause errors in your application depending on how it 
is written?

The new 3.1.1 version can be configured to create an anchor file.  If 
you delete that
then the Wrapper will shutdown.  But that is by design.

Cheers,
Leif

[Wrapper-user] OutOfMemoryError

[Nick R. <nic...@em...>]

The wrapper service was up running for a few hours and then it abruptly
stopped with the following log dump:


INFO   | jvm 1    | 2004/07/03 12:15:16 | WrapperSimpleApp: Encountered
an error running main: java.lang.OutOfMemoryError
INFO   | jvm 1    | 2004/07/03 12:15:16 | java.lang.OutOfMemoryError
INFO   | jvm 1    | 2004/07/03 12:15:16 | WrapperManager.stop(1) called
by thread: WrapperSimpleAppMain
INFO   | jvm 1    | 2004/07/03 12:15:16 | Send a packet STOP : 1
DEBUG  | wrapperp | 2004/07/03 12:15:16 | read a packet STOP : 1
DEBUG  | wrapper  | 2004/07/03 12:15:16 | JVM requested a shutdown. (1)
DEBUG  | wrapper  | 2004/07/03 12:15:16 | wrapperStopProcess(1) called.
DEBUG  | wrapper  | 2004/07/03 12:15:16 | Sending stop signal to JVM
DEBUG  | wrapperp | 2004/07/03 12:15:16 | send a packet STOP : NULL
INFO   | jvm 1    | 2004/07/03 12:15:16 | Received a packet STOP :
INFO   | jvm 1    | 2004/07/03 12:15:17 | Thread, WrapperSimpleAppMain,
handling the shutdown process.
INFO   | jvm 1    | 2004/07/03 12:15:17 | calling listener.stop()
INFO   | jvm 1    | 2004/07/03 12:15:17 | WrapperSimpleApp: stop(1)
INFO   | jvm 1    | 2004/07/03 12:15:17 | returned from listener.stop()
INFO   | jvm 1    | 2004/07/03 12:15:17 | Send a packet STOPPED : 0
DEBUG  | wrapperp | 2004/07/03 12:15:17 | read a packet STOPPED : 0
DEBUG  | wrapper  | 2004/07/03 12:15:17 | JVM signalled that it was
stopped.
INFO   | jvm 1    | 2004/07/03 12:15:17 | Closing socket.
DEBUG  | wrapperp | 2004/07/03 12:15:17 | socket read no code (closed?).
INFO   | jvm 1    | 2004/07/03 12:15:18 | calling System.exit(1)
INFO   | jvm 1    | 2004/07/03 12:15:18 | Server daemon shut down
DEBUG  | wrapper  | 2004/07/03 12:15:21 | JVM process exited with a code
of 1, however the wrapper exit code was already 1.
DEBUG  | wrapper  | 2004/07/03 12:15:21 | JVM exited normally.


Any clues?
-- 
  Nick Rice
  nic...@em...

[Wrapper-user] Re: Newbie - App Integration

[Nick R. <nic...@em...>]

Thanks for your assistance Leif. The instructions helped me setup the
wrapper and get it to work. Its working fine now. Once small issue I
came across was that if I manually deleted all the logs while the
wrapper service was running (as a daemon on Linux in this case), the
service would somehow stop on its own.

I will definately tell others about this neat utility and I will also
consider donating in the coming time.

Thanks again :)


-- 
  Nick Rice
  nic...@em...

----- Original message -----

Nick,
     You sound new to Java, so I"ll walk you through what is covered on 
 the following
 page :-)
 http://wrapper.tanukisoftware.org/doc/english/integrate.html
 
     When you get things working, please do think about remembering our
 helpfulness here :-)
 http://wrapper.tanukisoftware.org/doc/english/donate.html

:
:
:

http://sourceforge.net/mailarchive/forum.php?thread_id=5037527&forum_id=11948

:
:
:

Re: [Wrapper-user] Truncated log entries

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

Rick Szeto wrote:

> Great news. I hack you the source code for a larger buffer and is 
> sufficient for now.
> But now that you have it fixed to a more permanent solution, I will 
> switch over to
> that when it comes out.
>
> Any projections on when 3.1.1 will be ready?

I am working with a couple users to squash one last bug discovered in 
the final testing
of 3.1.1.   As soon as that is done, it is out the door.  It is taking a 
little bit of time
however... :-/

Cheers,
Leif

Re: [Wrapper-user] Truncated log entries

[Rick S. <rs...@as...>]

Great news. I hack you the source code for a larger buffer and is 
sufficient for now.
But now that you have it fixed to a more permanent solution, I will 
switch over to
that when it comes out.

Any projections on when 3.1.1 will be ready?

Thanks again,
Rick

Leif Mortenson wrote:

> Rick,
>    I sat down tonight and completely rewrote the function which reads 
> and then logs
> console output from the JVM.   The new routine now allocates its 
> internal buffer
> dynamically, growing as needed so there should no longer be any limit 
> to the length
> of output lines.
>
>    It is still possible that line feeds could be inserted for very 
> very long lines when the
> system is under high load.  This is because I only allow the main loop 
> to stay in that
> function for a certain period of time before breaking out to handle 
> more critical
> functions.   This should be rare however.
>
>    The great news is that comparing speed tests of the old version 
> with the new,
> I found that this rewrite has given the Wrapper a 4x speed increase 
> when processing
> large amounts of JVM output.   The Windows version had always been slower
> than the UNIX version.  But they are now about the same speed.
>
>    The UNIX version had already been making use of a dynamic buffer so 
> it was
> handling long lines correctly.
>
>    I want to do more load testing of this, but it will be in the 3.1.1 
> release.
>
> Cheers,
> Leif
>
> Rick Szeto wrote:
>
>> Leif,
>>   Some of our messages are pretty large(ie Base64 encoding of images, 
>> don't ask... :-[ ).
>> I think it is quite reasonable for there to be a fixed limit. I would 
>> propose 2048 or 4096
>> characters even. I would hazard to guess that performance would not 
>> degrade too badly
>> given a larger fixed buffer.
>>
>> What do you think?
>>
>> Rick
>>
>> Leif Mortenson wrote:
>>
>>> Rick,
>>>    Currently for performance reasons, a fixed buffer is used when 
>>> reading the JVM
>>> output.   The way it is implemented, this causes a linefeed each 
>>> 1024 characters
>>> for very long lines.   There is not a way to change this behavior in 
>>> the current release.
>>> I will look into getting that cleaned up.   It has been a minor 
>>> annoyance in a couple
>>> of my applications as well.
>>>    At some point, I want to make the buffer dynamically scale.  But 
>>> I am trying to
>>> get a release out.  If it is within reason, I can quickly up the 
>>> size a bit.  How long are
>>> the lines you are trying to log?
>>>
>>>    Glad to hear we are helping with mental health in our own little 
>>> way. :-)
>>>
>>> Cheers,
>>> Leif
>>>
>>> Rick Szeto wrote:
>>>
>>>> Hi all,
>>>>  I am experiencing long logs entries to the console logfile being 
>>>> truncated. Is there a configuration parameter I missing that will 
>>>> fix this? Or is this a know problem?
>>>>
>>>> Any help would be greatly appricated.
>>>>
>>>> BTW, the wrapper is the only thing that is keeping me sane in our 
>>>> production environment.
>>>> Thanks.
>>>>
>>>> Rick Szeto
>>>
>>>
>
>
>
> -------------------------------------------------------
> 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] Truncated log entries

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

Rick,
    I sat down tonight and completely rewrote the function which reads 
and then logs
console output from the JVM.   The new routine now allocates its 
internal buffer
dynamically, growing as needed so there should no longer be any limit to 
the length
of output lines.

    It is still possible that line feeds could be inserted for very very 
long lines when the
system is under high load.  This is because I only allow the main loop 
to stay in that
function for a certain period of time before breaking out to handle more 
critical
functions.   This should be rare however.

    The great news is that comparing speed tests of the old version with 
the new,
I found that this rewrite has given the Wrapper a 4x speed increase when 
processing
large amounts of JVM output.   The Windows version had always been slower
than the UNIX version.  But they are now about the same speed.

    The UNIX version had already been making use of a dynamic buffer so 
it was
handling long lines correctly.

    I want to do more load testing of this, but it will be in the 3.1.1 
release.

Cheers,
Leif

Rick Szeto wrote:

> Leif,
>   Some of our messages are pretty large(ie Base64 encoding of images, 
> don't ask... :-[ ).
> I think it is quite reasonable for there to be a fixed limit. I would 
> propose 2048 or 4096
> characters even. I would hazard to guess that performance would not 
> degrade too badly
> given a larger fixed buffer.
>
> What do you think?
>
> Rick
>
> Leif Mortenson wrote:
>
>> Rick,
>>    Currently for performance reasons, a fixed buffer is used when 
>> reading the JVM
>> output.   The way it is implemented, this causes a linefeed each 1024 
>> characters
>> for very long lines.   There is not a way to change this behavior in 
>> the current release.
>> I will look into getting that cleaned up.   It has been a minor 
>> annoyance in a couple
>> of my applications as well.
>>    At some point, I want to make the buffer dynamically scale.  But I 
>> am trying to
>> get a release out.  If it is within reason, I can quickly up the size 
>> a bit.  How long are
>> the lines you are trying to log?
>>
>>    Glad to hear we are helping with mental health in our own little 
>> way. :-)
>>
>> Cheers,
>> Leif
>>
>> Rick Szeto wrote:
>>
>>> Hi all,
>>>  I am experiencing long logs entries to the console logfile being 
>>> truncated. Is there a configuration parameter I missing that will 
>>> fix this? Or is this a know problem?
>>>
>>> Any help would be greatly appricated.
>>>
>>> BTW, the wrapper is the only thing that is keeping me sane in our 
>>> production environment.
>>> Thanks.
>>>
>>> Rick Szeto
>>

FW: [Wrapper-user] RE: [Wrapper-user]It worked: HP-UX 11i 64 bit:log level DEBUG crashes application

[Venkatesh S. <Ven...@lc...>]

++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Please read the disclaimer at the bottom of this e-mail.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

As an addendum,

The flags used for compiling the binary in Makefile.hpux did not work.
The ones that worked for me are:
cc -O3 -Wall -DHPUX -D_HPUX -D_POSIX_C_SOURCE=3D199506L -D_XOPEN_SOURCE_EXT=
ENDED -I$(INCLUDES) -$(SOURCES) -lm -o $(BINARY)

Cheers,

-----Original Message-----
From: wra...@li...
[mailto:wra...@li...]On Behalf Of Venkatesh
Sellappa
Sent: 01 July 2004 14:32
To: wra...@li...
Subject: RE: [Wrapper-user] RE: [Wrapper-user]It worked: HP-UX 11i 64
bit:log level DEBUG crashes application


++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Please read the disclaimer at the bottom of this e-mail.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Leif,

I had just noticed that as well.
Made the change.

It would be nice if we could get a single binary and library working for 32=
 and 64 bit Hp-UX.

Cheers,

-----Original Message-----
From: wra...@li...
[mailto:wra...@li...]On Behalf Of Leif
Mortenson
Sent: 01 July 2004 14:12
To: wra...@li...
Subject: Re: [Wrapper-user] RE: [Wrapper-user]It worked: HP-UX 11i 64
bit:log level DEBUG crashes application


Venkatesh,
    Great, glad that worked. The logs you sent me showed what I expected.
Go ahead and remove those debug log_printfs and use that until I am able=20
to get
the 3.1.1 release out the door.   That should be fairly soon I am=20
working with a
couple users to get a FreeBSD issue resolved with it and then it is out=20
the door

    It has been bugging as to why things had been working for you when DEBUG
was not enabled however.

    Looking at the code, I see the problem.  So make this one additional=20
change:
 From the patch I sent you today:
---
        if (len =3D=3D SOCKET_ERROR) {
            err =3D wrapperGetLastError();
            if (wrapperData->isDebugging) {
                if ((err !=3D EWOULDBLOCK) && (err !=3D EAGAIN)
                    && (err !=3D ENOTSOCK) && (err !=3D ECONNRESET)) {
                    log_printf(WRAPPER_SOURCE_PROTOCOL, LEVEL_DEBUG,
                        "socket read failed. (%s)", getLastErrorText());
                    wrapperProtocolClose();
                }
            }
---
Notice that the location of the isDebugging check is wrong.  It should=20
be changed to
the following:
---
        if (len =3D=3D SOCKET_ERROR) {
            err =3D wrapperGetLastError();
            if ((err !=3D EWOULDBLOCK) && (err !=3D EAGAIN)
                && (err !=3D ENOTSOCK) && (err !=3D ECONNRESET)) {
                if (wrapperData->isDebugging) {
                    log_printf(WRAPPER_SOURCE_PROTOCOL, LEVEL_DEBUG,
                        "socket read failed. (%s)", getLastErrorText());
                }
                wrapperProtocolClose();
            }
---
Now things should be correct if such a problem is ever encountered again.

Cheers,
Leif
.
Venkatesh Sellappa wrote:

>++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>Please read the disclaimer at the bottom of this e-mail.
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>Leif,
>
>Bingo !!!.
>It worked.
>
>On applying the below two patches, it worked.
>
>I think the key is that=20
>0.EWOULDBLOCK and EAGAIN constants in HP-UX have different values
>1.The test must be made for EAGAIN on accept and receive(for HP-UX)
>2.The constant EAGAIN is 11
>
>I have mailed you the log with the STATE_OUTPUT=3DTRUE.
>
>Thanks again for all the help.Much appreciated.
>Let me know if there is something else i can do.
>( removing the extra log_printf statements is a start ).
>
>Cheers,
> =20
>


**********************************************************************
This email is intended for the named recipient(s) only. Its contents
are  confidential and may only be retained by the named recipient(s)
and may only be copied or  disclosed  with the consent of=20
LCH.Clearnet Limited.   If you are not an intended recipient please
delete this e-mail and notify pos...@lc....

The contents  of this  email are  subject to  contract in all cases,=20
and LCH.Clearnet Limited makes no contractual commitment save where
confirmed by hard copy.  LCH.Clearnet Limited accepts no liability,=20
including liability for negligence, in respect of any statement in=20
this email.

LCH.Clearnet Limited, Registered Office: Aldgate House,=20
33 Aldgate High Street, London EC3N 1EA.    Recognised as a Clearing=20
House under the Financial Services & Markets Act 2000. Reg in England No.25=
932=20
Telephone: +44 20 7426 7000              Internet: http://www.lchclearnet.c=
om
**********************************************************************



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


**********************************************************************
This email is intended for the named recipient(s) only. Its contents
are  confidential and may only be retained by the named recipient(s)
and may only be copied or  disclosed  with the consent of=20
LCH.Clearnet Limited.   If you are not an intended recipient please
delete this e-mail and notify pos...@lc....

The contents  of this  email are  subject to  contract in all cases,=20
and LCH.Clearnet Limited makes no contractual commitment save where
confirmed by hard copy.  LCH.Clearnet Limited accepts no liability,=20
including liability for negligence, in respect of any statement in=20
this email.

LCH.Clearnet Limited, Registered Office: Aldgate House,=20
33 Aldgate High Street, London EC3N 1EA.    Recognised as a Clearing=20
House under the Financial Services & Markets Act 2000. Reg in England No.25=
932=20
Telephone: +44 20 7426 7000              Internet: http://www.lchclearnet.c=
om
**********************************************************************

RE: [Wrapper-user] RE: [Wrapper-user]It worked: HP-UX 11i 64 bit:log level DEBUG crashes application

[Venkatesh S. <Ven...@lc...>]

++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Please read the disclaimer at the bottom of this e-mail.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Leif,

I had just noticed that as well.
Made the change.

It would be nice if we could get a single binary and library working for 32=
 and 64 bit Hp-UX.

Cheers,

-----Original Message-----
From: wra...@li...
[mailto:wra...@li...]On Behalf Of Leif
Mortenson
Sent: 01 July 2004 14:12
To: wra...@li...
Subject: Re: [Wrapper-user] RE: [Wrapper-user]It worked: HP-UX 11i 64
bit:log level DEBUG crashes application


Venkatesh,
    Great, glad that worked. The logs you sent me showed what I expected.
Go ahead and remove those debug log_printfs and use that until I am able=20
to get
the 3.1.1 release out the door.   That should be fairly soon I am=20
working with a
couple users to get a FreeBSD issue resolved with it and then it is out=20
the door

    It has been bugging as to why things had been working for you when DEBUG
was not enabled however.

    Looking at the code, I see the problem.  So make this one additional=20
change:
 From the patch I sent you today:
---
        if (len =3D=3D SOCKET_ERROR) {
            err =3D wrapperGetLastError();
            if (wrapperData->isDebugging) {
                if ((err !=3D EWOULDBLOCK) && (err !=3D EAGAIN)
                    && (err !=3D ENOTSOCK) && (err !=3D ECONNRESET)) {
                    log_printf(WRAPPER_SOURCE_PROTOCOL, LEVEL_DEBUG,
                        "socket read failed. (%s)", getLastErrorText());
                    wrapperProtocolClose();
                }
            }
---
Notice that the location of the isDebugging check is wrong.  It should=20
be changed to
the following:
---
        if (len =3D=3D SOCKET_ERROR) {
            err =3D wrapperGetLastError();
            if ((err !=3D EWOULDBLOCK) && (err !=3D EAGAIN)
                && (err !=3D ENOTSOCK) && (err !=3D ECONNRESET)) {
                if (wrapperData->isDebugging) {
                    log_printf(WRAPPER_SOURCE_PROTOCOL, LEVEL_DEBUG,
                        "socket read failed. (%s)", getLastErrorText());
                }
                wrapperProtocolClose();
            }
---
Now things should be correct if such a problem is ever encountered again.

Cheers,
Leif
.
Venkatesh Sellappa wrote:

>++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>Please read the disclaimer at the bottom of this e-mail.
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>Leif,
>
>Bingo !!!.
>It worked.
>
>On applying the below two patches, it worked.
>
>I think the key is that=20
>0.EWOULDBLOCK and EAGAIN constants in HP-UX have different values
>1.The test must be made for EAGAIN on accept and receive(for HP-UX)
>2.The constant EAGAIN is 11
>
>I have mailed you the log with the STATE_OUTPUT=3DTRUE.
>
>Thanks again for all the help.Much appreciated.
>Let me know if there is something else i can do.
>( removing the extra log_printf statements is a start ).
>
>Cheers,
> =20
>


**********************************************************************
This email is intended for the named recipient(s) only. Its contents
are  confidential and may only be retained by the named recipient(s)
and may only be copied or  disclosed  with the consent of=20
LCH.Clearnet Limited.   If you are not an intended recipient please
delete this e-mail and notify pos...@lc....

The contents  of this  email are  subject to  contract in all cases,=20
and LCH.Clearnet Limited makes no contractual commitment save where
confirmed by hard copy.  LCH.Clearnet Limited accepts no liability,=20
including liability for negligence, in respect of any statement in=20
this email.

LCH.Clearnet Limited, Registered Office: Aldgate House,=20
33 Aldgate High Street, London EC3N 1EA.    Recognised as a Clearing=20
House under the Financial Services & Markets Act 2000. Reg in England No.25=
932=20
Telephone: +44 20 7426 7000              Internet: http://www.lchclearnet.c=
om
**********************************************************************

Re: [Wrapper-user] RE: [Wrapper-user]It worked: HP-UX 11i 64 bit:log level DEBUG crashes application

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

Venkatesh,
    Great, glad that worked. The logs you sent me showed what I expected.
Go ahead and remove those debug log_printfs and use that until I am able 
to get
the 3.1.1 release out the door.   That should be fairly soon I am 
working with a
couple users to get a FreeBSD issue resolved with it and then it is out 
the door

    It has been bugging as to why things had been working for you when DEBUG
was not enabled however.

    Looking at the code, I see the problem.  So make this one additional 
change:
 From the patch I sent you today:
---
        if (len == SOCKET_ERROR) {
            err = wrapperGetLastError();
            if (wrapperData->isDebugging) {
                if ((err != EWOULDBLOCK) && (err != EAGAIN)
                    && (err != ENOTSOCK) && (err != ECONNRESET)) {
                    log_printf(WRAPPER_SOURCE_PROTOCOL, LEVEL_DEBUG,
                        "socket read failed. (%s)", getLastErrorText());
                    wrapperProtocolClose();
                }
            }
---
Notice that the location of the isDebugging check is wrong.  It should 
be changed to
the following:
---
        if (len == SOCKET_ERROR) {
            err = wrapperGetLastError();
            if ((err != EWOULDBLOCK) && (err != EAGAIN)
                && (err != ENOTSOCK) && (err != ECONNRESET)) {
                if (wrapperData->isDebugging) {
                    log_printf(WRAPPER_SOURCE_PROTOCOL, LEVEL_DEBUG,
                        "socket read failed. (%s)", getLastErrorText());
                }
                wrapperProtocolClose();
            }
---
Now things should be correct if such a problem is ever encountered again.

Cheers,
Leif
.
Venkatesh Sellappa wrote:

>++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>Please read the disclaimer at the bottom of this e-mail.
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>Leif,
>
>Bingo !!!.
>It worked.
>
>On applying the below two patches, it worked.
>
>I think the key is that 
>0.EWOULDBLOCK and EAGAIN constants in HP-UX have different values
>1.The test must be made for EAGAIN on accept and receive(for HP-UX)
>2.The constant EAGAIN is 11
>
>I have mailed you the log with the STATE_OUTPUT=TRUE.
>
>Thanks again for all the help.Much appreciated.
>Let me know if there is something else i can do.
>( removing the extra log_printf statements is a start ).
>
>Cheers,
>  
>

[Wrapper-user] RE: [Wrapper-user]It worked: HP-UX 11i 64 bit:log level DEBUG crashes application

[Venkatesh S. <Ven...@lc...>]

++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Please read the disclaimer at the bottom of this e-mail.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Leif,

Bingo !!!.
It worked.

On applying the below two patches, it worked.

I think the key is that=20
0.EWOULDBLOCK and EAGAIN constants in HP-UX have different values
1.The test must be made for EAGAIN on accept and receive(for HP-UX)
2.The constant EAGAIN is 11

I have mailed you the log with the STATE_OUTPUT=3DTRUE.

Thanks again for all the help.Much appreciated.
Let me know if there is something else i can do.
( removing the extra log_printf statements is a start ).

Cheers,

-----Original Message-----
From: wra...@li...
[mailto:wra...@li...]On Behalf Of Leif
Mortenson
Sent: 01 July 2004 05:12
To: wra...@li...
Subject: Re: [Wrapper-user] HP-UX 11i 64 bit:log level DEBUG crashes
application


Venkatesh,
    Ok, I think I know what the problem is.  I found this message:
http://lists.parisc-linux.org/pipermail/parisc-linux/2004-March/022504.html

    It comments on the EWOULDBLOCK and EAGAIN constants not being
equal on HPUX like they are on Linux.   I am testing for EWOULDBLOCK,
but reviewing the accept man page, it looks like I should be testing for=20
EAGAIN.

    Could try out a couple more changes to the code and let me know how they
work out?

    The first is to modify the tests just after the accept call on or=20
about wrapper.c:552
Old:
---
    if (sd =3D=3D INVALID_SOCKET) {
        rc =3D wrapperGetLastError();
        if (rc =3D=3D EWOULDBLOCK) {
            /* There are no incomming sockets right now. */
            return;
        } else {
            if (wrapperData->isDebugging) {
                log_printf(WRAPPER_SOURCE_PROTOCOL, LEVEL_DEBUG,
                    "socket creation failed. (%s)", getLastErrorText());
            }
            return;
        }
    }
---
New:
---
    if (sd =3D=3D INVALID_SOCKET) {
        rc =3D wrapperGetLastError();
        log_printf(WRAPPER_SOURCE_PROTOCOL, LEVEL_DEBUG,
            "errno 11 =3D %s", strerror(11));
        log_printf(WRAPPER_SOURCE_PROTOCOL, LEVEL_DEBUG,
            "errno EWOULDBLOCK =3D %d =3D %s", EWOULDBLOCK,=20
strerror(EWOULDBLOCK));
        log_printf(WRAPPER_SOURCE_PROTOCOL, LEVEL_DEBUG,
            "errno EAGAIN =3D %d =3D %s", EAGAIN, strerror(EAGAIN));
        /* EWOULDBLOCK !=3D EAGAIN on some platforms. */
        if ((rc =3D=3D EWOULDBLOCK) || (rc =3D=3D EAGAIN)) {
            /* There are no incomming sockets right now. */
            return;
        } else {
            if (wrapperData->isDebugging) {
                log_printf(WRAPPER_SOURCE_PROTOCOL, LEVEL_DEBUG,
                    "socket creation failed. (%s)", getLastErrorText());
            }
            return;
        }
    }
---
I am expecting that EAGAIN =3D 11 on your system.   If not, then I would=20
appreciate
it if you could figure out what constant is =3D 11 on your machine.  =20
Assuming for now
that it is, then the patch above and the one that follows should fix=20
your problem.

The second patch is for the test just after the recv call at or around=20
line 793.
Old:
---
        len =3D recv(sd, &c, 1, 0);
        if (len =3D=3D SOCKET_ERROR) {
            err =3D wrapperGetLastError();
            if (wrapperData->isDebugging) {
                if ((err !=3D EWOULDBLOCK) && (err !=3D ENOTSOCK) && (err !=
=3D=20
ECONNRESET)) {
                    log_printf(WRAPPER_SOURCE_PROTOCOL, LEVEL_DEBUG,
                        "socket read failed. (%s)", getLastErrorText());
                    wrapperProtocolClose();
                }
            }
---
New:
---
        len =3D recv(sd, &c, 1, 0);
        if (len =3D=3D SOCKET_ERROR) {
            err =3D wrapperGetLastError();
            if (wrapperData->isDebugging) {
                if ((err !=3D EWOULDBLOCK) && (err !=3D EAGAIN)
                    && (err !=3D ENOTSOCK) && (err !=3D ECONNRESET)) {
                    log_printf(WRAPPER_SOURCE_PROTOCOL, LEVEL_DEBUG,
                        "socket read failed. (%s)", getLastErrorText());
                    wrapperProtocolClose();
                }
            }
---

Cheers,
Leif

Venkatesh Sellappa wrote:

>Hi List,
>
>I think we got a little bit more visibility on this.
>Having made the changes to wrapper.c and re-compiling.
>I still get the same error.
>
>The value of EWOULDBLOCK in this case is not 11 but 246.
>
>I have mailed you the log file with all the gory details.
>
>Cheers,
>
> =20
>
<snip>


**********************************************************************
This email is intended for the named recipient(s) only. Its contents
are  confidential and may only be retained by the named recipient(s)
and may only be copied or  disclosed  with the consent of=20
LCH.Clearnet Limited.   If you are not an intended recipient please
delete this e-mail and notify pos...@lc....

The contents  of this  email are  subject to  contract in all cases,=20
and LCH.Clearnet Limited makes no contractual commitment save where
confirmed by hard copy.  LCH.Clearnet Limited accepts no liability,=20
including liability for negligence, in respect of any statement in=20
this email.

LCH.Clearnet Limited, Registered Office: Aldgate House,=20
33 Aldgate High Street, London EC3N 1EA.    Recognised as a Clearing=20
House under the Financial Services & Markets Act 2000. Reg in England No.25=
932=20
Telephone: +44 20 7426 7000              Internet: http://www.lchclearnet.c=
om
**********************************************************************

Re: [Wrapper-user] Re: Newbie - App Integration

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

Nick,
    I noticed one mistake in step 6e.  See below.  I want to keep this 
together
for the archives.

Leif Mortenson wrote:

> Nick,
>    You sound new to Java, so I'll walk you through what is covered on 
> the following
> page :-)
> http://wrapper.tanukisoftware.org/doc/english/integrate.html
>
>    When you get things working, please do think about remembering our
> helpfulness here :-)
> http://wrapper.tanukisoftware.org/doc/english/donate.html
>
> 1) Lets start out by creating a directory structure where %APP_HOME% 
> is the base
> directory of your application.
>
> %APP_HOME%\bin
> %APP_HOME%\conf
> %APP_HOME%\lib
> %APP_HOME%\lib\classes
> %APP_HOME%\logs
>
> 2) First we need want to put your two class files into the 
> %APP_HOME%\lib\classes
> directory.  I would suggest eventually putting them into a jar file 
> and making use
> of package names, but that is not necessary.
>
> 3) Copy the 3 template batch files from the Wrapper distribution into 
> your bin directory
> as follows.   Replace MyApp with the name of your application:
> copy %WRAPPER_HOME%\src\bin\App.bat.in %APP_HOME%\bin\MyApp.bat
> copy %WRAPPER_HOME%\src\bin\InstallApp-NT.bat.in 
> %APP_HOME%\bin\InstallMyApp-NT.bat
> copy %WRAPPER_HOME%\src\bin\UninstallApp-NT.bat.in 
> %APP_HOME%\bin\UninstallMyApp-NT.bat
>
> 4) Copy the following 3 binary files from the Wrapper distribution 
> into your bin and
> lib directories as follows:
> copy %WRAPPER_HOME%\bin\Wrapper.exe %APP_HOME%\bin\Wrapper.exe
> copy %WRAPPER_HOME%\lib\wrapper.dll %APP_HOME%\lib\wrapper.dll
> copy %WRAPPER_HOME%\lib\wrapper.jar %APP_HOME%\lib\wrapper.jar
>
> 5) Copy the template wrapper.conf file as follows:
> copy %WRAPPER_HOME%\src\conf\wrapper.conf.in %APP_HOME%\conf\wrapper.conf
>
> 6) Ok, now all of your files are in place.  We now need to edit the 
> wrapper.conf file
> so it will work with your application.
>
> 6a) Depending on how your system is set up, you may need to hard code 
> in the
> location of the java.exe on your system.  Realize that it may or may 
> not be
> configured correctly on your path when running as a service.
>
> The following default may work correctly.
> wrapper.java.command=java
>
> But you may need to set it to something like:
> wrapper.java.command=%JAVA_HOME%/bin/java
>
> Or even:
> wrapper.java.command=C:/j2sdk1.4.2_04/bin/java
>
> 6b) In this case, for the main java class, we are going to be using 
> integration
> method #1, so we will set it as follows:
> wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
>
> 6c) The classpath will need to include both the wrapper.jar file and 
> your classes
> directory.  These paths and all other paths can either be hard coded 
> or defined
> relative to the location of the Wrapper.exe file.  I would suggest the 
> later as it
> enables you to install your application on any machine at any location 
> without any
> changes to the configuration file.
> wrapper.java.classpath.1=../lib/wrapper.jar
> wrapper.java.classpath.2=../lib/classes
>
> 6d) The library path specifies the location of wrapper.dll and any 
> other native
> libraries that your application may use.  In this case, the default is 
> ok.
> wrapper.java.library.path.1=../lib
>
> 6e) The above WrapperSimpleApp helper class expects that its first 
> argument
> will be the name of your application's main class.  We specify this as 
> follows.
> If you need to pass any arguments to your main method, then add them 
> after
> the main class, incrementing the .1 number after each property
> wrapper.java.additional.1=Pserver

This should have been the following:
wrapper.app.parameter.1=Pserver

The java additional properties are for setting options to the JVM itself.

> 6f) For now, we can leave the logging properties alone.  But if you 
> run into any
> problems then you will want to set the following property and try 
> again.   If the
> resulting %APP_HOME%/logs/wrapper.log file contents do not make sense,
> then I will need to see that file and the wrapper.conf file you are 
> currently editing
> to be able to help further.
>
> 6g) At the bottom of the file, we want to set the following properties 
> do define
> how your application is registered as an NT service.
> wrapper.ntservice.name=myapp
> wrapper.ntservice.displayname=My Application
> wrapper.ntservice.description=My Application Server
>
> 6h) Save the wrapper.conf file.
>
> 7) We are now ready to run.  Start out by opening a command prompt
> and cd-ing into your %APP_HOME%/bin directory.
> Try running the application in console mode by running the MyApp.bat
> file.   Your application should start up and work correctly.
>
> 8) Stop your program with CTRL-C.   Because your main runner thread
> is not configured as a Daemon thread, the java application may or may
> not shutdown promptly.   Let me know if after 30 seconds you are getting
> a message about the JVM not shutting down cleanly.   The Wrapper will
> forcibly kill the JVM process in such situations.
>
> 9) If everything is going well to this point, we are ready to try 
> running your
> application as a service.   First we need to install it by running
> InstallMyApp-NT.bat
> Next you can start it by running "net start myapp" from the console, or
> starting the service from within the Services control panel.
> You should see a message saying that the service was started.
> Try testing it out.  And review the contents of the wrapper.log file 
> to see
> if you are getting any unexpected errors.
> The service is now configured to startup when the system is rebooted.
>
> 10)  You can stop the service from the control panel or by executing
> "net stop myapp" from a console.   Running UninstallMyApp-NT.bat
> will of course uninstall the service.
>
> That should cover it.  See 0 lines of Java code involved :-)  Let me know
> if I missed anything or if you run into any problems.
>
> Cheers,
> Leif
>
> Nick Rice wrote:
>
>> Thanks for your reply Leif.
>>
>> I'm running the app simply as "java Pserver.class" in the console. The
>> Pserver.java looks like:
>>
>> import java.io.*;
>> import java.net.*;
>>
>> public class Pserver {
>>
>>    public static void main(String[] args)    {
>>        ServerSocket serverSocket;
>>        Socket client;
>>        Pthread thClient;
>>
>>        try
>>        {
>>
>>            serverSocket=new ServerSocket(39823);
>>            while(true)
>>            {
>>                client=serverSocket.accept();
>>                thClient = new Pthread(client);
>>                thClient.run();
>>            }
>>
>>        }
>>        catch(Exception e)
>>        {
>>            e.printStackTrace();
>>        }
>>    }
>>
>> }
>>
>>
>> Can u please give me an example on the above code, as to how to
>> implement the helper class and what configuration to use for the
>> wrapper. Maybe I am thinking too hard :)
>>
>> Thanks for your help mate!
>>
>>
>>
>> -------------------------------------
>>
>>
>> Nick,
>>     How are you running your application without the Wrapper?  If you 
>> use method 1,
>> with the WrapperSimpleApp helper class, there is zero special coding 
>> that you will
>> have to do.
>>     You simply specify your main class as the argument to the 
>> WrapperSimpleApp
>> helper class and you are up and running.
>>
>>     It sounds like your Pserver and Pthread classes are both running 
>> in the same
>> JVM? Correct?   Post how you normally run them from a console and I"ll
>> tell
>> you what you need to do to use the Wrapper.   I have a feeling that 
>> you are just
>> thinking too hard :-)
>>
>> Cheers,
>> Leif
>>
>> Nick Rice wrote:
>>
>> >Hello All,
>> >
>> >This wrapper is exactly what I"ve was looking for. But I need some help
>> >on how to go about integrating it with my application. See, I have a 
>> two
>> >java class files (say Pserver.class and Pthread.class). Pserver listens
>> >as a server socket (i.e. in a while loop), and it passes the socket
>> >client to the Pthread class which processes the incoming data. Now, in
>> >this scenario, how can I go about integrating the Pserver as an
>> >unmanaged service. I read the docs but I"m not sure which of the three
>> >integration methods is most suitable in my case. I tried playing with
>> >the first (simpler) integration method but due to my limited Java
>> >knowledge I could not get it to run as a service. I guess what I"m
>> >missing is hot to integrate the wrapper and my Pserver class. Can
>> >someone provide more details on how to impelment the helper class in my
>> >Pserver class and then finally where to specify the wrapper to use the
>> >modified Pserver.
>> >
>> >Any help is much appreciated. Thanks :)
>>   
>

Re: [Wrapper-user] Re: Newbie - App Integration

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

Nick,
    You sound new to Java, so I'll walk you through what is covered on 
the following
page :-)
http://wrapper.tanukisoftware.org/doc/english/integrate.html

    When you get things working, please do think about remembering our
helpfulness here :-)
http://wrapper.tanukisoftware.org/doc/english/donate.html

1) Lets start out by creating a directory structure where %APP_HOME% is 
the base
directory of your application.

%APP_HOME%\bin
%APP_HOME%\conf
%APP_HOME%\lib
%APP_HOME%\lib\classes
%APP_HOME%\logs

2) First we need want to put your two class files into the 
%APP_HOME%\lib\classes
directory.  I would suggest eventually putting them into a jar file and 
making use
of package names, but that is not necessary.

3) Copy the 3 template batch files from the Wrapper distribution into 
your bin directory
as follows.   Replace MyApp with the name of your application:
copy %WRAPPER_HOME%\src\bin\App.bat.in %APP_HOME%\bin\MyApp.bat
copy %WRAPPER_HOME%\src\bin\InstallApp-NT.bat.in 
%APP_HOME%\bin\InstallMyApp-NT.bat
copy %WRAPPER_HOME%\src\bin\UninstallApp-NT.bat.in 
%APP_HOME%\bin\UninstallMyApp-NT.bat

4) Copy the following 3 binary files from the Wrapper distribution into 
your bin and
lib directories as follows:
copy %WRAPPER_HOME%\bin\Wrapper.exe %APP_HOME%\bin\Wrapper.exe
copy %WRAPPER_HOME%\lib\wrapper.dll %APP_HOME%\lib\wrapper.dll
copy %WRAPPER_HOME%\lib\wrapper.jar %APP_HOME%\lib\wrapper.jar

5) Copy the template wrapper.conf file as follows:
copy %WRAPPER_HOME%\src\conf\wrapper.conf.in %APP_HOME%\conf\wrapper.conf

6) Ok, now all of your files are in place.  We now need to edit the 
wrapper.conf file
so it will work with your application.

6a) Depending on how your system is set up, you may need to hard code in the
location of the java.exe on your system.  Realize that it may or may not be
configured correctly on your path when running as a service.

The following default may work correctly.
wrapper.java.command=java

But you may need to set it to something like:
wrapper.java.command=%JAVA_HOME%/bin/java

Or even:
wrapper.java.command=C:/j2sdk1.4.2_04/bin/java

6b) In this case, for the main java class, we are going to be using 
integration
method #1, so we will set it as follows:
wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp

6c) The classpath will need to include both the wrapper.jar file and 
your classes
directory.  These paths and all other paths can either be hard coded or 
defined
relative to the location of the Wrapper.exe file.  I would suggest the 
later as it
enables you to install your application on any machine at any location 
without any
changes to the configuration file.
wrapper.java.classpath.1=../lib/wrapper.jar
wrapper.java.classpath.2=../lib/classes

6d) The library path specifies the location of wrapper.dll and any other 
native
libraries that your application may use.  In this case, the default is ok.
wrapper.java.library.path.1=../lib

6e) The above WrapperSimpleApp helper class expects that its first argument
will be the name of your application's main class.  We specify this as 
follows.
If you need to pass any arguments to your main method, then add them after
the main class, incrementing the .1 number after each property
wrapper.java.additional.1=Pserver

6f) For now, we can leave the logging properties alone.  But if you run 
into any
problems then you will want to set the following property and try 
again.   If the
resulting %APP_HOME%/logs/wrapper.log file contents do not make sense,
then I will need to see that file and the wrapper.conf file you are 
currently editing
to be able to help further.

6g) At the bottom of the file, we want to set the following properties 
do define
how your application is registered as an NT service.
wrapper.ntservice.name=myapp
wrapper.ntservice.displayname=My Application
wrapper.ntservice.description=My Application Server

6h) Save the wrapper.conf file.

7) We are now ready to run.  Start out by opening a command prompt
and cd-ing into your %APP_HOME%/bin directory.
Try running the application in console mode by running the MyApp.bat
file.   Your application should start up and work correctly.

8) Stop your program with CTRL-C.   Because your main runner thread
is not configured as a Daemon thread, the java application may or may
not shutdown promptly.   Let me know if after 30 seconds you are getting
a message about the JVM not shutting down cleanly.   The Wrapper will
forcibly kill the JVM process in such situations.

9) If everything is going well to this point, we are ready to try 
running your
application as a service.   First we need to install it by running
InstallMyApp-NT.bat
Next you can start it by running "net start myapp" from the console, or
starting the service from within the Services control panel.
You should see a message saying that the service was started.
Try testing it out.  And review the contents of the wrapper.log file to see
if you are getting any unexpected errors.
The service is now configured to startup when the system is rebooted.

10)  You can stop the service from the control panel or by executing
"net stop myapp" from a console.   Running UninstallMyApp-NT.bat
will of course uninstall the service.

That should cover it.  See 0 lines of Java code involved :-)  Let me know
if I missed anything or if you run into any problems.

Cheers,
Leif

Nick Rice wrote:

>Thanks for your reply Leif.
>
>I'm running the app simply as "java Pserver.class" in the console. The
>Pserver.java looks like:
>
>import java.io.*;
>import java.net.*;
>
>public class Pserver {
>
>    public static void main(String[] args) 
>    {
>        ServerSocket serverSocket;
>        Socket client;
>        Pthread thClient;
>
>        try
>        {
>
>            serverSocket=new ServerSocket(39823);
>            while(true)
>            {
>                client=serverSocket.accept();
>                thClient = new Pthread(client);
>                thClient.run();
>            }
>
>        }
>        catch(Exception e)
>        {
>            e.printStackTrace();
>        }
>    }
>
>}
>
>
>Can u please give me an example on the above code, as to how to
>implement the helper class and what configuration to use for the
>wrapper. Maybe I am thinking too hard :)
>
>Thanks for your help mate!
>
>
>
>-------------------------------------
>
>
>Nick,
>     How are you running your application without the Wrapper?  If you 
> use method 1,
> with the WrapperSimpleApp helper class, there is zero special coding 
> that you will
> have to do.
>     You simply specify your main class as the argument to the 
> WrapperSimpleApp
> helper class and you are up and running.
> 
>     It sounds like your Pserver and Pthread classes are both running in 
> the same
> JVM? Correct?   Post how you normally run them from a console and I"ll
> tell
> you what you need to do to use the Wrapper.   I have a feeling that you 
> are just
> thinking too hard :-)
> 
> Cheers,
> Leif
> 
> Nick Rice wrote:
> 
> >Hello All,
> >
> >This wrapper is exactly what I"ve was looking for. But I need some help
> >on how to go about integrating it with my application. See, I have a two
> >java class files (say Pserver.class and Pthread.class). Pserver listens
> >as a server socket (i.e. in a while loop), and it passes the socket
> >client to the Pthread class which processes the incoming data. Now, in
> >this scenario, how can I go about integrating the Pserver as an
> >unmanaged service. I read the docs but I"m not sure which of the three
> >integration methods is most suitable in my case. I tried playing with
> >the first (simpler) integration method but due to my limited Java
> >knowledge I could not get it to run as a service. I guess what I"m
> >missing is hot to integrate the wrapper and my Pserver class. Can
> >someone provide more details on how to impelment the helper class in my
> >Pserver class and then finally where to specify the wrapper to use the
> >modified Pserver.
> >
> >Any help is much appreciated. Thanks :)
>  
>