Menu
▾
▴
wrapper-user
|
From: Justin <ju...@io...> - 2003-08-20 16:45:54
|
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 |
|
From: Leif M. <le...@ta...> - 2003-08-20 17:31:49
|
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,
>
>
>
|
|
From: Sal I. <sal...@sy...> - 2003-08-22 02:03:51
|
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
|
|
From: Leif M. <le...@ta...> - 2003-09-03 14:51:14
|
Sal,
I liked this idea. It has been implemented and will be in the 3.0.5
release.
I wrote up some docs for the JBoss case, but still need to do so for the
Sun JMX RI example. If you have any ideas for the docs, please let me know.
The new code and existing docs are now all checked into CVS, if you
want to
try checking them out and do some testing, I would appreciate it. Also
if you have
any comments on the published API, before the release is the time to get any
changes in. Note that the public CVS is currently running 24 hours behind.
I also placed a pair of source snapshots up on my server if you prefer.
(They are not 24 hours behind :-)
http://wrapper.tanukisoftware.org/tmp/wrapper_3.0.5b_src_with_doc_src.tar.gz
http://wrapper.tanukisoftware.org/tmp/wrapper_3.0.5b_src_with_doc_src.zip
The new docs are at /doc/english/jmx.html
Cheers,
Leif
Sal Ingrilli wrote:
>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
>
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: VM Ware
>With VMware you can run multiple operating systems on a single machine.
>WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
>at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...
>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>
>
|
|
From: Richard E. <rem...@ed...> - 2003-09-16 16:15:06
|
So I've got 3.0.5 running with my jboss application. I set wrapper.debug=true, just to see whats happening. I get printout that the native library was loaded... INFO | jvm 1 | 2003/09/16 08:55:12 | Calling native initialization method. INFO | jvm 1 | 2003/09/16 08:55:12 | Inside native WrapperManager initialization method INFO | jvm 1 | 2003/09/16 08:55:12 | Java Version : 1.4.2-b28 Java HotSpot(TM) Client VM INFO | jvm 1 | 2003/09/16 08:55:12 | Java VM Vendor : Sun Microsystems Inc. INFO | jvm 1 | 2003/09/16 08:55:12 | INFO | jvm 1 | 2003/09/16 08:55:12 | Wrapper (Version 3.0.5) INFO | jvm 1 | 2003/09/16 08:55:12 | INFO | jvm 1 | 2003/09/16 08:55:12 | Open socket to wrapper... INFO | jvm 1 | 2003/09/16 08:55:12 | Opened Socket INFO | jvm 1 | 2003/09/16 08:55:12 | Send a packet KEY : XGuDK_MTRJ8iZjZ3 etc...... I start getting debug printout: DEBUG | wrapperp | 2003/09/16 08:56:35 | send a packet PING : ping INFO | jvm 1 | 2003/09/16 08:56:35 | Received a packet PING : ping INFO | jvm 1 | 2003/09/16 08:56:35 | Send a packet PING : ok DEBUG | wrapperp | 2003/09/16 08:56:35 | read a packet PING : ok DEBUG | wrapper | 2003/09/16 08:56:35 | Got ping response from JVM DEBUG | wrapperp | 2003/09/16 08:56:41 | send a packet PING : ping but when I press 'invoke' on the methods requestThreadDump on the jmx mbean page for the wrapper nothing happens. Well, I do advance to a followup jboss web page, but there is no thread dump. Not on the web page or any of the logs. In fact, the debug information in the native (linux) method Java_org_tanukisoftware_wrapper_WrapperManager_nativeRequestThreadDump does not print. No errors, no nothing. Where is the thread dump output suppose to go? Thanks. Richard |
|
From: Leif M. <le...@ta...> - 2003-09-17 09:23:29
|
Richard,
It sounds like you are doing things correctly. I retested this
today using JBoss and
Java 1.4.2_01 but everything appears to be working correctly. I tried
the JMX interface
while running in both console mode and running as an NT service.
The thread dump will be dumped to both the console and wrapper.log
file at the INFO
level.
When running in console mode are you able to invoke a thread dump using
CTRL-BREAK on Windows or CTRL-\ on UNIX. On unix, you should also be
able to invoke a thread dumb executing the wrapper script used to launch
the application
with the dump command.
I'll test this out on Linux tonight as that may be what you are running?
Cheers,
Leif
> So I've got 3.0.5 running with my jboss application. I set
> wrapper.debug=true, just to see whats happening.
> I get printout that the native library was loaded...
>
>
> INFO | jvm 1 | 2003/09/16 08:55:12 | Calling native
> initialization method.
> INFO | jvm 1 | 2003/09/16 08:55:12 | Inside native WrapperManager
> initialization method
> INFO | jvm 1 | 2003/09/16 08:55:12 | Java Version : 1.4.2-b28
> Java HotSpot(TM) Client VM
> INFO | jvm 1 | 2003/09/16 08:55:12 | Java VM Vendor : Sun
> Microsystems Inc.
> INFO | jvm 1 | 2003/09/16 08:55:12 |
> INFO | jvm 1 | 2003/09/16 08:55:12 | Wrapper (Version 3.0.5)
> INFO | jvm 1 | 2003/09/16 08:55:12 |
> INFO | jvm 1 | 2003/09/16 08:55:12 | Open socket to wrapper...
> INFO | jvm 1 | 2003/09/16 08:55:12 | Opened Socket
> INFO | jvm 1 | 2003/09/16 08:55:12 | Send a packet KEY :
> XGuDK_MTRJ8iZjZ3
> etc......
>
> I start getting debug printout:
>
> DEBUG | wrapperp | 2003/09/16 08:56:35 | send a packet PING : ping
> INFO | jvm 1 | 2003/09/16 08:56:35 | Received a packet PING : ping
> INFO | jvm 1 | 2003/09/16 08:56:35 | Send a packet PING : ok
> DEBUG | wrapperp | 2003/09/16 08:56:35 | read a packet PING : ok
> DEBUG | wrapper | 2003/09/16 08:56:35 | Got ping response from JVM
> DEBUG | wrapperp | 2003/09/16 08:56:41 | send a packet PING : ping
>
> but when I press 'invoke' on the methods requestThreadDump
> on the jmx mbean page for the wrapper nothing happens.
> Well, I do advance to a followup jboss web page, but there is
> no thread dump. Not on the web page or any of the logs. In fact,
> the debug information in the native (linux) method
> Java_org_tanukisoftware_wrapper_WrapperManager_nativeRequestThreadDump
> does not print.
>
> No errors, no nothing. Where is the thread dump output suppose to
> go?
>
> Thanks.
>
>
> Richard
|
|
From: Richard E. <rem...@ed...> - 2003-09-17 14:01:18
|
I do launch the java with the flag '-Xrs'; maybe that prevents the signal from being seen. Richard Leif Mortenson wrote: > Richard, > It sounds like you are doing things correctly. I retested this today > using JBoss and > Java 1.4.2_01 but everything appears to be working correctly. I tried > the JMX interface > while running in both console mode and running as an NT service. > The thread dump will be dumped to both the console and wrapper.log > file at the INFO > level. > When running in console mode are you able to invoke a thread dump using > CTRL-BREAK on Windows or CTRL-\ on UNIX. On unix, you should also be > able to invoke a thread dumb executing the wrapper script used to launch > the application > with the dump command. > I'll test this out on Linux tonight as that may be what you are running? > > Cheers, > Leif > >> So I've got 3.0.5 running with my jboss application. I set >> wrapper.debug=true, just to see whats happening. >> I get printout that the native library was loaded... >> >> >> INFO | jvm 1 | 2003/09/16 08:55:12 | Calling native >> initialization method. >> INFO | jvm 1 | 2003/09/16 08:55:12 | Inside native WrapperManager >> initialization method >> INFO | jvm 1 | 2003/09/16 08:55:12 | Java Version : 1.4.2-b28 >> Java HotSpot(TM) Client VM >> INFO | jvm 1 | 2003/09/16 08:55:12 | Java VM Vendor : Sun >> Microsystems Inc. >> INFO | jvm 1 | 2003/09/16 08:55:12 | >> INFO | jvm 1 | 2003/09/16 08:55:12 | Wrapper (Version 3.0.5) >> INFO | jvm 1 | 2003/09/16 08:55:12 | >> INFO | jvm 1 | 2003/09/16 08:55:12 | Open socket to wrapper... >> INFO | jvm 1 | 2003/09/16 08:55:12 | Opened Socket >> INFO | jvm 1 | 2003/09/16 08:55:12 | Send a packet KEY : >> XGuDK_MTRJ8iZjZ3 >> etc...... >> >> I start getting debug printout: >> >> DEBUG | wrapperp | 2003/09/16 08:56:35 | send a packet PING : ping >> INFO | jvm 1 | 2003/09/16 08:56:35 | Received a packet PING : ping >> INFO | jvm 1 | 2003/09/16 08:56:35 | Send a packet PING : ok >> DEBUG | wrapperp | 2003/09/16 08:56:35 | read a packet PING : ok >> DEBUG | wrapper | 2003/09/16 08:56:35 | Got ping response from JVM >> DEBUG | wrapperp | 2003/09/16 08:56:41 | send a packet PING : ping >> >> but when I press 'invoke' on the methods requestThreadDump >> on the jmx mbean page for the wrapper nothing happens. >> Well, I do advance to a followup jboss web page, but there is >> no thread dump. Not on the web page or any of the logs. In fact, >> the debug information in the native (linux) method >> Java_org_tanukisoftware_wrapper_WrapperManager_nativeRequestThreadDump >> does not print. >> >> No errors, no nothing. Where is the thread dump output suppose to >> go? >> >> Thanks. >> >> >> Richard > > > > > > > ------------------------------------------------------- > 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 > |
|
From: Leif M. <le...@ta...> - 2003-09-25 05:41:05
|
Richard,
I tested this on both Linux and Windows using the -Xrs flag. In
both cases, the JVM
halts immediately without executing any shutdown hooks when you request
a thread dump.
That's not good. But there is nothing I can do about it. I'll add a
note to the documentation
about it though.
You were seeing something slightly different, but that may be due to
the exact JVM you
are using. Have you had a chance to try this out removing the -Xrs flag?
Cheers,
Leif
Richard Emberson wrote:
> I do launch the java with the flag '-Xrs'; maybe that
> prevents the signal from being seen.
>
> Richard
>
>
> Leif Mortenson wrote:
>
>> Richard,
>> It sounds like you are doing things correctly. I retested this
>> today using JBoss and
>> Java 1.4.2_01 but everything appears to be working correctly. I
>> tried the JMX interface
>> while running in both console mode and running as an NT service.
>> The thread dump will be dumped to both the console and wrapper.log
>> file at the INFO
>> level.
>> When running in console mode are you able to invoke a thread dump
>> using
>> CTRL-BREAK on Windows or CTRL-\ on UNIX. On unix, you should also be
>> able to invoke a thread dumb executing the wrapper script used to
>> launch the application
>> with the dump command.
>> I'll test this out on Linux tonight as that may be what you are
>> running?
>>
>> Cheers,
>> Leif
>>
>>> So I've got 3.0.5 running with my jboss application. I set
>>> wrapper.debug=true, just to see whats happening.
>>> I get printout that the native library was loaded...
>>>
>>>
>>> INFO | jvm 1 | 2003/09/16 08:55:12 | Calling native
>>> initialization method.
>>> INFO | jvm 1 | 2003/09/16 08:55:12 | Inside native
>>> WrapperManager initialization method
>>> INFO | jvm 1 | 2003/09/16 08:55:12 | Java Version : 1.4.2-b28
>>> Java HotSpot(TM) Client VM
>>> INFO | jvm 1 | 2003/09/16 08:55:12 | Java VM Vendor : Sun
>>> Microsystems Inc.
>>> INFO | jvm 1 | 2003/09/16 08:55:12 |
>>> INFO | jvm 1 | 2003/09/16 08:55:12 | Wrapper (Version 3.0.5)
>>> INFO | jvm 1 | 2003/09/16 08:55:12 |
>>> INFO | jvm 1 | 2003/09/16 08:55:12 | Open socket to wrapper...
>>> INFO | jvm 1 | 2003/09/16 08:55:12 | Opened Socket
>>> INFO | jvm 1 | 2003/09/16 08:55:12 | Send a packet KEY :
>>> XGuDK_MTRJ8iZjZ3
>>> etc......
>>>
>>> I start getting debug printout:
>>>
>>> DEBUG | wrapperp | 2003/09/16 08:56:35 | send a packet PING : ping
>>> INFO | jvm 1 | 2003/09/16 08:56:35 | Received a packet PING : ping
>>> INFO | jvm 1 | 2003/09/16 08:56:35 | Send a packet PING : ok
>>> DEBUG | wrapperp | 2003/09/16 08:56:35 | read a packet PING : ok
>>> DEBUG | wrapper | 2003/09/16 08:56:35 | Got ping response from JVM
>>> DEBUG | wrapperp | 2003/09/16 08:56:41 | send a packet PING : ping
>>>
>>> but when I press 'invoke' on the methods requestThreadDump
>>> on the jmx mbean page for the wrapper nothing happens.
>>> Well, I do advance to a followup jboss web page, but there is
>>> no thread dump. Not on the web page or any of the logs. In fact,
>>> the debug information in the native (linux) method
>>> Java_org_tanukisoftware_wrapper_WrapperManager_nativeRequestThreadDump
>>> does not print.
>>>
>>> No errors, no nothing. Where is the thread dump output suppose to
>>> go?
>>>
>>> Thanks.
>>>
>>>
>>> Richard
>>
|
