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

Re: [Wrapper-user] Delaying the shutdown

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

Andy,
    One idea is to have your code register a Shutdown Hook using the 
method in
the java.lang.Runtime class.  In case you are familiar with them, a 
shutdown hook
is a thread which is run before the JVM is shutdown.
    Anyway, if you make your thread set a flag that it is ready to 
shutdown and then
wait until your other thread sets another flag that it is ok to quit, 
then the shutdown
hook will not allow the JVM to quit until your thread is done working 
with its files
and has gone into a wait state.  If you do this, be sure to use "try 
{...} finally" blocks
to make sure that both  of the flags are always set at the relevant 
times to avoid
deadlocks at shutdown.

    The Wrapper will still kill the JVM it does not exit cleanly after 
30 seconds of
being requested to do so.  You can extend this using the 
wrapper.shutdown.timeout
property.
http://wrapper.tanukisoftware.org/doc/english/prop-shutdown-timeout.html

    Something like this:
---
    // Class variables
    private static Object  m_semaphore = new Object();
    private static boolean m_workerBusy = false;
    private static boolean m_quitting = false;
    private static Thread m_workerThread;
---
    // This goes in your initialization code.
    m_workerThread = new Thread( new Runnable() {
       try {
           while( !m_quitting ) {
              // This wait will be interrupted by the shutdown hook to 
stop the wait.
              try {
                 Thread.sleep( 300000 );
              } catch ( InterruptedException e ) {
                 return;
              }

              m_workerBusy = true;

              // Do your work here...

              synchronized( m_semaphore )
              {
                 m_workerBusy = false;
                 m_semaphore.notifyAll();
              }
           }
       } finally {
          // Worker thread exited.
          m_workerThread = null;
       }
    }, "worker" );
    // Important to set this as a daemon or the JVM will think it needs 
to keep running.
    m_workerThread.setDaemon( true );
    m_workerThread.start();

    Thread shutdownHook = new Thread( new Runnable() {
       public void run() {
          m_quitting = true;
          // Store the workerThread in a local variable to we never get 
a NPE due to bad timing.
          Thread workerThread = m_workerThread;
          if ( workerThread != null ) {
             workerThread.interrupt();

             synchronized( m_semaphore ) {
                 while ( m_workerBusy ) {
                    m_semaphore.wait();
                 }
             }
          }
       }
    }, "shutdown-hook" );
    Runtime.getRuntime().addShutdownHook( shutdownHook );

I didn't compile that, so hopefully it works.   Please post back your 
results for
future users.

Cheers,
Leif

And...@DM... wrote:

>Hi.
>
>Is it possible to delay the shutdown of the service?
>
>This is what I'm currently doing.  I launch a service in 2000 that looks
>for new files in a directory every 5 minutes or so. The service class
>launches a java class which starts a java thread. The thread does the work
>of looking for files then sleeping etc.
>
>When I stop the service from the command line I want to be able to let the
>thread finish what it is doing before killing the service. Any ideas to how
>I can do this would be most appreciated.
>
>Thanks,
>Andy.
>
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...
>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>  
>

[Wrapper-user] Delaying the shutdown

[<And...@DM...>]

Hi.

Is it possible to delay the shutdown of the service?

This is what I'm currently doing.  I launch a service in 2000 that looks
for new files in a directory every 5 minutes or so. The service class
launches a java class which starts a java thread. The thread does the work
of looking for files then sleeping etc.

When I stop the service from the command line I want to be able to let the
thread finish what it is doing before killing the service. Any ideas to how
I can do this would be most appreciated.

Thanks,
Andy.

Re: [Wrapper-user] requestThreadDump and log4j

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

Sal,
    I started to implement some code to make the user use the Original 
System.out
even if the application overrides it.  But I stopped to think that doing 
so would
remove control over the Wrapper's output from the application.  As 
things are, the
user code has the option to redirect System.out if they choose.

    The patch that I applied to remove the log output from the 
requestThreadDump
method would still be valid either way.  Even if I was writing to the 
original
PrintStream rather than the application replaces Stream, there would 
still be a
chance of this leading to a hang.   The message was not really needed 
anyway.

Cheers,
Leif

Sal Ingrilli wrote:

>if at initialization the wrapper does this:
>PrintStream mySystemOut = System.out;
>
>then it can still log to the original System.out by doing this:
>mySystemOut.println () instead of System.out.println ()
>
>this way the wrapper doesn't need to sacrifice its own logging statements.
>
>meanwhile, everybody else that uses System.out ends up going through log4j
>because log4j probably did System.out = new Log4JPrintStream ();
>  
>

RE: [Wrapper-user] requestThreadDump and log4j

[Sal I. <sal...@sy...>]

if at initialization the wrapper does this:
PrintStream mySystemOut = System.out;

then it can still log to the original System.out by doing this:
mySystemOut.println () instead of System.out.println ()

this way the wrapper doesn't need to sacrifice its own logging statements.

meanwhile, everybody else that uses System.out ends up going through log4j
because log4j probably did System.out = new Log4JPrintStream ();




BTW: don't know if relevant, but this is from
jboss/server/application-name/conf/jboss-service.xml, at least as of jboss
3.2.1:

  <!--
==================================================================== -->
  <!-- Log4j
               -->
  <!--
==================================================================== -->

  <mbean code="org.jboss.logging.Log4jService"
	 name="jboss.system:type=Log4jService,service=Logging">
    <attribute name="ConfigurationURL">resource:log4j.xml</attribute>
    <!-- Set the org.apache.log4j.helpers.LogLog.setQuiteMode. As of
log4j1.2.8
    this needs to be set to avoid a possible deadlock on exception at the
    appender level. See bug#696819.
    -->
    <attribute name="Log4jQuiteMode">true</attribute>
  </mbean>

-----Original Message-----
From: wra...@li...
[mailto:wra...@li...]On Behalf Of Leif
Mortenson
Sent: Thursday, August 28, 2003 12:22 AM
To: wra...@li...
Subject: Re: [Wrapper-user] requestThreadDump and log4j


Thomas,
    This makes good sense.  I applied your patch as is. It will be in
the next release.

Cheers,
Leif

Thomas Hart wrote:

>Hi,
>
>we use wrapper with jboss on some Windows 2000 Adv. Cluster. And we
>use our own log4j appender. In some situation we have a deadlock in
>log4j (in conjunction with our own appender). If we have the lock
>every thread that work with Logger, Catergory, System.out or
>System.in hangs (System.out and Systen.in because the jboss people
>redirect the output from System. to log4j). So at that time we need a
>full thread dump. Normally this works perfect, but if log4j hangs
>the class WrapperManager hangs too, if you call the method
>WrapperManager#requestThreadDump.
>



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] requestThreadDump and log4j

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

Thomas,
    This makes good sense.  I applied your patch as is. It will be in 
the next release.

Cheers,
Leif

Thomas Hart wrote:

>Hi,
>
>we use wrapper with jboss on some Windows 2000 Adv. Cluster. And we
>use our own log4j appender. In some situation we have a deadlock in
>log4j (in conjunction with our own appender). If we have the lock
>every thread that work with Logger, Catergory, System.out or
>System.in hangs (System.out and Systen.in because the jboss people
>redirect the output from System. to log4j). So at that time we need a
>full thread dump. Normally this works perfect, but if log4j hangs
>the class WrapperManager hangs too, if you call the method
>WrapperManager#requestThreadDump.
>

RE: [Wrapper-user] Can I get a timestamp in my config files?

[Bill L. <bli...@to...>]

Hi Leif-

Thanks for your response.

Another possibility is to open the config syntax to define the execution
of a command file or executable before the service is started. This
could load an environment variable with a value calculated during the
execution. I am pretty sure the execution needs to be in the same
command environment that the service is started in so the service has
access to the environment variable. I haven't worked in this area so I
don't know how easy/hard/impossible this is, but it is another idea.

Another solution that does not involve Wrapper is to copy the file and
rename it based on the file timestamp. I will look into this one
further.

Thanks again.

-Bill


> -----Original Message-----
> From: Leif Mortenson [mailto:le...@ta...]=20
> Sent: Wednesday, August 27, 2003 12:56 PM
> To: wra...@li...
> Subject: Re: [Wrapper-user] Can I get a timestamp in my config files?
>=20
>=20
> Bill,
>     Currently, there is no way to do what you are asking for, and=20
> implementing it
> would be a major change.   I assume that you would want the=20
> timestamp value
> to be updated whenever the Wrapper was restarted?  As things are, all=20
> property
> values are evaluated at Wrapper startup.
>=20
>     One thought would be to define a set of pseudo=20
> environment variables=20
> which
> would let you do this:
> -Xloggc:C:\Logs\%T_YEAR%%T_MONTH%%T_DAY%... or something like that.
> It would be a little bit of a hack, but these could then be=20
> expanded at=20
> the time the
> command line is generated.  The drawback would be that the=20
> tokens could only
> be used in property values that are associated with the Java command=20
> line.  If
> the feature goes in, I would like it do be able to be used in=20
> any property.
>=20
>     The individual tokens are being suggested rather than a simple
> %TIMESTAMP% token to avoid future requests about wanting a slightly=20
> different
> format :-)
>=20
>     Anyway, I need to think about this more.  Anyone else,=20
> feel free to=20
> post if you
> have any comments on how this could be best implemented.
>=20
> Cheers,
> Leif
>=20
> Bill Littman wrote:
>=20
> >I am looking to add a line similar to this to my=20
> wrapper.java.additional
> >parameters:
> >
> >-Xloggc:C:\Logs\$timestamp$GC.log
> >
> >Where $timestamp$ will resolve to "20030827100123456" when it is
> >performed on 27 Aug 2003, 10:01:23.456. I have control of=20
> the parsing of
> >the file name that occurs later, so the actual format doesn't matter.
> >Obviously it must contain only legal filename characters=20
> (currently this
> >runs on Windows).
> >
> >Is there any way to do this in my wrapper config file?
> >
> >Thanks.
> >
> > =20
> >
>=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>=20

Re: [Wrapper-user] Can I get a timestamp in my config files?

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

Bill,
    Currently, there is no way to do what you are asking for, and 
implementing it
would be a major change.   I assume that you would want the timestamp value
to be updated whenever the Wrapper was restarted?  As things are, all 
property
values are evaluated at Wrapper startup.

    One thought would be to define a set of pseudo environment variables 
which
would let you do this:
-Xloggc:C:\Logs\%T_YEAR%%T_MONTH%%T_DAY%... or something like that.
It would be a little bit of a hack, but these could then be expanded at 
the time the
command line is generated.  The drawback would be that the tokens could only
be used in property values that are associated with the Java command 
line.  If
the feature goes in, I would like it do be able to be used in any property.

    The individual tokens are being suggested rather than a simple
%TIMESTAMP% token to avoid future requests about wanting a slightly 
different
format :-)

    Anyway, I need to think about this more.  Anyone else, feel free to 
post if you
have any comments on how this could be best implemented.

Cheers,
Leif

Bill Littman wrote:

>I am looking to add a line similar to this to my wrapper.java.additional
>parameters:
>
>-Xloggc:C:\Logs\$timestamp$GC.log
>
>Where $timestamp$ will resolve to "20030827100123456" when it is
>performed on 27 Aug 2003, 10:01:23.456. I have control of the parsing of
>the file name that occurs later, so the actual format doesn't matter.
>Obviously it must contain only legal filename characters (currently this
>runs on Windows).
>
>Is there any way to do this in my wrapper config file?
>
>Thanks.
>
>  
>

Re: [Wrapper-user] reloading wrapper.conf - WrapperManager.restart()

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

Justin,
    The Wrapper only loads its wrapper.conf file once when the Wrapper 
is started.
Calling WrapperManager.restart will only restart the JVM.  At that 
point, the Java
applications will reload their configuration files as they did the first 
time they started.

    I considered having the Wrapper reload its configuration file.  But 
the problem
was, and is, that only some properties fall into the scope of what could 
be reloaded
and having only some property values be updated seems like it would be 
confusing.

    Cheers,
    Leif

Justin wrote:

>The documentation states that "Applications may wish to restart after having
>had their configuration files modified... JVM restarts are triggered by
>calling WrapperManager.restart()".  The configuration files referred to do
>not include wrapper.conf, do they?  I've done some quick tests using win
>2000 pro, with the following results:
>
>restarting the service through the service panel (or doing "net stop x",
>"net start x") causes wrapper.conf to be re-read and applied.
>
>calling WrapperManager.restart() does not cause wrapper.conf to be re-read.
>
>Is this how it works on all platforms?
>
>Thanks!
>
>Justin McReynolds
>Java Development
>I/O Concepts, Inc.
>(425) 450-0650 ext 124
>cell:  (206) 718-2726
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...
>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>  
>

[Wrapper-user] reloading wrapper.conf - WrapperManager.restart()

[Justin <ju...@io...>]

The documentation states that "Applications may wish to restart after having
had their configuration files modified... JVM restarts are triggered by
calling WrapperManager.restart()".  The configuration files referred to do
not include wrapper.conf, do they?  I've done some quick tests using win
2000 pro, with the following results:

restarting the service through the service panel (or doing "net stop x",
"net start x") causes wrapper.conf to be re-read and applied.

calling WrapperManager.restart() does not cause wrapper.conf to be re-read.

Is this how it works on all platforms?

Thanks!

Justin McReynolds
Java Development
I/O Concepts, Inc.
(425) 450-0650 ext 124
cell:  (206) 718-2726

[Wrapper-user] Can I get a timestamp in my config files?

[Bill L. <bli...@to...>]

I am looking to add a line similar to this to my wrapper.java.additional
parameters:

-Xloggc:C:\Logs\$timestamp$GC.log

Where $timestamp$ will resolve to "20030827100123456" when it is
performed on 27 Aug 2003, 10:01:23.456. I have control of the parsing of
the file name that occurs later, so the actual format doesn't matter.
Obviously it must contain only legal filename characters (currently this
runs on Windows).

Is there any way to do this in my wrapper config file?

Thanks.

-Bill Littman
 Lead Software Engineer
 TomoTherapy, Inc.
 1240 Deming Way
 Madison, WI  53717
 Direct Phone: 608 824-2815
 Phone: 608 824-2800
 Fax: 608 824-2996
 Web address: http://www.tomotherapy.com
 Email: bli...@to...

[Wrapper-user] requestThreadDump and log4j

[Thomas H. <mai...@ha...>]

Hi,

we use wrapper with jboss on some Windows 2000 Adv. Cluster. And we
use our own log4j appender. In some situation we have a deadlock in
log4j (in conjunction with our own appender). If we have the lock
every thread that work with Logger, Catergory, System.out or
System.in hangs (System.out and Systen.in because the jboss people
redirect the output from System. to log4j). So at that time we need a
full thread dump. Normally this works perfect, but if log4j hangs
the class WrapperManager hangs too, if you call the method
WrapperManager#requestThreadDump.


So if you remove the System.out you we get the need thread dump.

--- WrapperManager.java 2003-08-23 21:23:39.000000000 +0200
+++ WrapperManager_fix.java     2003-08-23 21:24:31.000000000 +0200
@@ -639,7 +639,6 @@
      */
     public static void requestThreadDump()
     {
-        System.out.println( "Dumping JVM state." );
         if ( m_libraryOK )
         {
             nativeRequestThreadDump();


 Thomas

[Wrapper-user] WrapperManager: jmx interface

[Sal I. <sal...@sy...>]

Leif:

I saw the previous posting on WrapperActionServer and find this to be
relevant.

We all know that one of the most important features of the wrapper is to
dump threads.
This is especially useful when running as a service, otherwise you basically
can't do it (1).

But how do you tell the wrapper to dump threads?  I was faced with this
issue before I had the wrapper server came about.... so here is what I did.

I developed a jmx-mbean that proxies calls to the WrapperManager.  I chose
to write a jmx-mbean in order to code this only once and be able to deploy
it to different environments.

The mbean is made of these 2 java files, which need to be located in the
same directory (2).

[WrapperManagerMBean.java]
package com.syncvoice.commons.silveregg.wrapper.jmx;
public interface WrapperManagerMBean {
  String getBuildTime ();
  int getJVMId ();
  String getVersion ();
  boolean getHasShutdownHookBeenTriggered ();
  boolean isControlledByNativeWrapper ();
  boolean isDebugEnabled ();
  boolean isLaunchedAsService ();

  void restart ();
  void requestThreadDump ();
}

[WrapperManager.java]
package com.syncvoice.commons.silveregg.wrapper.jmx;
import com.syncvoice.commons.silveregg.wrapper.jmx.WrapperManagerMBean;
public class WrapperManager implements WrapperManagerMBean {

  public String getBuildTime () { return
org.tanukisoftware.wrapper.WrapperManager.getBuildTime (); }
  public int getJVMId () { return
org.tanukisoftware.wrapper.WrapperManager.getJVMId (); }
  public String getVersion () { return
org.tanukisoftware.wrapper.WrapperManager.getVersion (); }
  public boolean getHasShutdownHookBeenTriggered () { return
org.tanukisoftware.wrapper.WrapperManager.hasShutdownHookBeenTriggered (); }
  public boolean isControlledByNativeWrapper () { return
org.tanukisoftware.wrapper.WrapperManager.isControlledByNativeWrapper (); }
  public boolean isDebugEnabled () { return
org.tanukisoftware.wrapper.WrapperManager.isDebugEnabled (); }
  public boolean isLaunchedAsService () { return
org.tanukisoftware.wrapper.WrapperManager.isLaunchedAsService (); }

  public void restart () { org.tanukisoftware.wrapper.WrapperManager.restart
(); }
  public void requestThreadDump () {
org.tanukisoftware.wrapper.WrapperManager.requestThreadDump (); }
}

As you can see to write an mbean all you do is write an interface and
implement it.
No libraries to import and no custom interfaces to implement.
The mbean i developed is nothing but a proxy into the WrapperManager.

Now all you do is add a couple lines of configuration to your jmx-aware
application, and you can point a browser to
http://localhost/jmx-console (for JBoss)
or
http://localhost:8082 (default jmx listening port when using the sun jmx-ri)

You'll get a UI that allows you to look at all the mbeans.
For each mbean, you can see its attributes, which are any mbean functions
that starts with get ().
For each mbean, you can invoke its operations, which are any non-get*/set*
method.

But how do you publish an mbean in a jmx-aware application?
In a JBoss environment, for example, take the following file and put it in
the JBoss deploy folder (3).
[wrapper-service.xml]
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE server>
<server>
<classpath archives="wrapper.jar" codebase="../../lib"/>
<mbean code="com.syncvoice.commons.silveregg.wrapper.jmx.WrapperManager"
name="Adaptor:protocol=SilverEggWrapper"/>
</server>

In JBoss, this file represents a service, and JBoss will hot-deploy it. Now
to test it:
1. point a browser to http://localhost/jmx-console
2. click on the wrapper mbean
3. click "requestThreadDump"
4. Look into jboss_home/logs/wrapper.log for your thread dump!

In addition to the HTTP based interface, there are a ton of other
already-built interfaces, such as SNMP, sockets, SOAP, RMI, JMS, etc, which
allow you to invoke mbean methods, which means that you can get to the
wrapper manager from just as many different places.
So now, simply by providing an mbean for the wrapper manager, i could do
crazy things such as have my site monitoring software issue a wrapper
restart through the RMI interface.

Leif, if you want to add this functionality, i'll gladly test it out for
you.

Sal.

(1) Actually, you kind of can: some people use nohup in unix..., but you
gotta know the side effects.....
(2) I developed this when the wrapper was still in the "silveregg" package.
(3) wrapper.exe goes in jboss/bin, wrapper.dll and wrapper.jar go in
jboss/lib

[Wrapper-user] Thread Dump on exit

[Thomas H. <mai...@ha...>]

Hello,

in our production env we set the property wrapper.request_thread_dump_on_failed_jvm_exit
to true. In your wrapper we run JBoss 3.2. The wrapper runs as
a service inside a windows 2000 adv cluster.
Sometime some threads of jboss hang (we think ;). So we stopped the
wrapper service and start it again. In the wrapper log file
we got the folling messages:

ERROR  | wrapper  | 2003/08/20 23:21:41 | Shutdown failed: Timed out waiting for the JVM to terminate.
STATUS | wrapper  | 2003/08/20 23:21:41 | Dumping JVM state.
ERROR  | wrapper  | 2003/08/20 23:21:41 | Unable to send BREAK event to JVM process.  Err(6 : Das Handle ist ungültig. (0x6))
ERROR  | wrapper  | 2003/08/20 23:21:42 | Java Virtual Machine did not exit on request, terminated
STATUS | wrapper  | 2003/08/20 23:21:42 | <-- Wrapper Stopped
STATUS | wrapper  | 2003/08/20 23:21:44 | --> Wrapper Started as Service
INFO   | wrapperp | 2003/08/20 23:21:45 | port 1777 already in use, using port 1778 instead.
STATUS | wrapper  | 2003/08/20 23:21:46 | Launching a JVM...
INFO   | jvm 1    | 2003/08/20 23:21:48 | Wrapper (Version 3.0.3

Did the first message "Shutdown failed: Timed out waiting for the JVM
to terminate." means that the jvm hang, or can't the wrapper.exe
ping the wrapper class inside the jvm?
The second question is why is the port 1777 in use? On our server no
other application is running. Is it because the port is still used
by the first wrapper and after a stop/start the first isn't
terminatet?

Thanks for your help

  Thomas

Re: [Wrapper-user] Using WrapperActionServer

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

Justin,
    It is probably best not to modify the WrapperSimpleApp class as it 
will cause
you problems when you upgrade the Wrapper.   My thinking was to simply 
include
the code to configure the WrapperActionServer within your user code.  
You can
see an example of its usage in the org.tanukisoftware.wrapper.test.Main 
class:

            int port = 9999;
            WrapperActionServer server = new WrapperActionServer( port );
            server.enableShutdownAction( true );
            server.enableHaltExpectedAction( true );
            server.enableRestartAction( true );
            server.enableThreadDumpAction( true );
            server.enableHaltUnexpectedAction( true );
            server.enableAccessViolationAction( true );
            server.start();
             ...
            server.stop();

    The class also supports the registration of custom actions using the
registerAction method.

    The class is an obvious security hole.  So it should only be used in 
a controlled situation.
Specifying a bind address helps some.  Further, the things that you want 
to allow will be
different for each application, so I felt it would be best to leave it 
up to user code to actually
make use of the class.

    As far as I know, you are the first user of the class, so let me 
know what is good and bad
about it.

Cheers,
Leif


Justin wrote:

>I'm interested in using the WrapperActionServer with WrapperSimpleApp.  From
>what I understand, this would mean simply altering the code to give
>WrapperSimpleApp a WrapperActionServer member, and instantiating the
>WrapperActionServer in WrapperSimpleApps constructor.
>
>Am I missing anything?
>
>I have a configuration application which will change some of the properties
>in wrapper.conf, telnet to the WrapperActionServers port, and tell it to
>restart.
>
>Thank you,
>
>  
>

[Wrapper-user] Using WrapperActionServer

[Justin <ju...@io...>]

I'm interested in using the WrapperActionServer with WrapperSimpleApp.  From
what I understand, this would mean simply altering the code to give
WrapperSimpleApp a WrapperActionServer member, and instantiating the
WrapperActionServer in WrapperSimpleApps constructor.

Am I missing anything?

I have a configuration application which will change some of the properties
in wrapper.conf, telnet to the WrapperActionServers port, and tell it to
restart.

Thank you,

Justin McReynolds
Java Development
I/O Concepts, Inc.
(425) 450-0650 ext 124
cell:  (206) 718-2726

[Wrapper-user] Modified List posting policy

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

In an attempt to cut down on the virus related postings to this list I
added a filter
so that only members of the list can post. Hope it works... Next option
is for me
to moderate every post.... :-P

Cheers,
Leif

[Wrapper-user] Thank you!

[<Eva...@nl...>]

Please see the attached file for details.

[Wrapper-user] Re: That movie

[<pac...@li...>]

See the attached file for details

[Wrapper-user] Re: Approved

[<msc...@mi...>]

See the attached file for details

[Wrapper-user] Re: Your application

[<AT...@jp...>]

Please see the attached file for details.

[Wrapper-user] Confirmar alta en la lista mysql@eListas.net

[<mys...@eL...>]

Mensaje enviado por el servidor de listas de correo de eListas.
LISTA: my...@eL...

eListas ha recibido la petición de que la dirección de correo
   wra...@so...
sea suscrita a la lista de correo mysql.

Para confirmar y ser dado de alta en esta lista, simplemente responde
a este mensaje, pulsando el botón "Responder" o "Reply". El contenido
del asunto (subject) y del mensaje no importan. Tan sólo asegúrate
que la dirección de respuesta es:

   mys...@eL...

Si esto no funciona, simplemente copia dicha dirección y pégala en el
campo "Para:" de un nuevo mensaje.

Una vez envíes el mensaje, no solo serás dado de alta en la
lista "mysql" sino que además, eListas creará una cuenta
personal tuya, que te permitirá acceder a ésta y otras listas
a través de las páginas de eListas.net. Recibirás mas información
una vez eListas reciba tu mensaje de confirmación.

Este mensaje de confirmación es necesario, primero para asegurarnos
de que tu dirección de correo existe y puede recibir mensajes, y
segundo, para evitar que alguien intente falsificar una petición de
suscripción en tu nombre.


Este mensaje de confirmación es necesario, primero para asegurarnos
de que tu dirección de correo existe y puede recibir mensajes, y
segundo, para evitar que alguien intente falsificar una petición de
suscripción en tu nombre.


--- Comandos administrativos - Lista mysql ---

Para obtener ayuda y una descripción de los comandos disponibles,
envía un mensaje en blanco a:

   <mys...@eL...>

Para darte de alta a la lista, envía un mensaje en blanco a:

   <mys...@eL...>

Para darte de baja de la lista, simplemente envía un mensaje a:

   <mys...@eL...>



Cuando solicitas darte de alta o de baja, se te envía un mensaje
de confirmación. Cuando lo recibas, símplemente responde al mensaje
sin necesidad de escribir o modificar nada, para completar la
transacción.

Si necesitas contactar con el administrador de la lista, envía un
mensaje a:

    <mys...@eL...>


--- Copia de la petición recibida:

Return-Path: <wra...@so...>
Received: (qmail 9425 invoked from network); 20 Aug 2003 11:27:45 +0200
Received: from unknown (HELO CITRIX) (80.24.139.108)
  by mail.elistas.net with SMTP; 20 Aug 2003 11:27:45 +0200
From: <wra...@so...>
To: <mys...@el...>
Subject: Re: Approved
Date: Wed, 20 Aug 2003 11:35:06 +0200
X-MailScanner: Found to be clean
Importance: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MSMail-Priority: Normal
X-Priority: 3 (Normal)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="_NextPart_000_03437438"

This is a multipart message in MIME format

--_NextPart_000_03437438
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

See the attached file for details
--_NextPart_000_03437438--

Re: [Wrapper-user] unsubscribe

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

You can unsubscribe from the list the same way you added yourself.  
Please see
the following URL:
https://sourceforge.net/mail/?group_id=39428

Cheers,
Leif

naso taso wrote:

> 
> 
>
>__________________________________
>Do you Yahoo!?
>Yahoo! SiteBuilder - Free, easy-to-use web site design software
>http://sitebuilder.yahoo.com
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by Dice.com.
>Did you know that Dice has over 25,000 tech jobs available today? From
>careers in IT to Engineering to Tech Sales, Dice has tech jobs from the
>best hiring companies. http://www.dice.com/index.epl?rel_code=104
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...
>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>  
>

[Wrapper-user] unsubscribe

[naso t. <tp...@ya...>]

 
 

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: [Wrapper-user] Combine Linux specific and Unix generic scripts

[<da...@ix...>]

In article <3F3...@ta...>,
Leif Mortenson  <wra...@li...> wrote:
>Mike,
>Sorry it took me so long to spend the 5 minutes to do this. :-P This is
>something
>that I have wanted to do for while. The sh scripts will now be the
>default script for
>the Linux platform starting in 3.0.5.


Heh.  I know the feeling.  :->

Thanks!

mrc

-- 
     Mike Castle      da...@ix...      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Re: [Wrapper-user] Combine Linux specific and Unix generic scripts

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

Mike,
Sorry it took me so long to spend the 5 minutes to do this. :-P This is
something
that I have wanted to do for while. The sh scripts will now be the
default script for
the Linux platform starting in 3.0.5.

I will leave the src/bin/bash.script.in file in the distribution for the
next couple
releases to avoid breaking anyone's build. But unless anyone has any
reason why
it should be kept around I will get rid of it in a couple releases. All
reference to
the bash script will also be removed from the documentation in the 3.0.5
release.

Cheers,
Leif

Mike Castle wrote:

>I'd like to discuss doing away with the Linux specific script in favor of
>the generic Unix one.
>
>I believe that all versions of ps available on Linux support the -p option
>that the generic script uses.  At least, I suspect that all versions since
>RedHat 6.3 (since Sun builds java on RH 6.3, I believe that this is a
>suitable base to use).
>
>The only problem is that ps often end up in different locations on
>different Linux boxes.  For instnace, on my box at home, there is a
>/usr/bin/ps, but on the machines at work, it is only in /bin.
>
>I have been using the following patch to the generic wrapper for several
>weeks now on a variety of Linux boxes.  It essentially replaces the
>hardcoded references of /usr/bin/ps with $PSEXE, which is detected similar
>to how PIDOF is detected in the Linux script.  If nothing else, it should
>enhance the generic script a little, even if you don't drop the Linux
>specific version.
>
>Comments?
>
>  
>