Hi Kieran
you have to change the server's /etc/hosts to:
127.0.0.1localhost.localdomain localhost
::1localhost6.localdomain6 localhost6
192.168.1.168 server.domain.tld server
192.168.3.168 hostname.domain.tld hostname
The line for 192.168.1.168 may not be necessary,
you may remove IPv6 line if you have not enabled it (generally I disable IPV6
where I doesn't need it)
what does "hostname -f " return ?
Do you need to bind wotaskd or applications's port to 192.168.3.168 only ?
Using WOHost makes applications binding their WOPort to a specific IP.
WOHost has never been necessary for me, even if the server has multiple IP
rely on iptables if you want to just allow connections on the IP you want.
I think using WOHost only complicate things.
Aurélien
On 11/19/2010 07:57 PM, Kieran Kelleher wrote:
Hi Aurélien,
OK, we are only using IP addresses in WOMonitor, no hostnames at all.
The linux server has two interfaces
eth0192.168.1.168
eth1192.168.3.168
Our WOA subnet is on 192.168.3.*
The /etc/hosts on that linux server right now has only this
127.0.0.1localhost.localdomain localhost
::1localhost6.localdomain6 localhost6
*The wotaskd Properties file has this added:*
WOHost=192.168.3.168
*The wotaskd debugging output for starting an app and communication looks like
this:*
@@@@@ monitorRequestAction received request from Monitor
[2010-11-19 13:53:37 EST] <WorkerThread1> @@@@@ monitorRequestAction
requestDict: {commandWotaskd = ( START,
{applicationName = "kieran-temp"; port = 2001; id = 1; hostName =
"192.168.3.168"; } ); }
[2010-11-19 13:53:37 EST] <WorkerThread1> Starting
Instance: /opt/next/Library/WebObjects/JavaApplications/wotaskd.woa/Contents/Resources/SpawnOfWotaskd.sh /Library/WebObjects/Applications/cheetah_1787_20101119_0807.woa/cheetah_1787
-WOHost 192.168.3.168 -WOPort 2001 -WOCachingEnabled YES -WODebuggingEnabled NO -WOOutputPath /dev/null
-WOAutoOpenInBrowser NO -WOAutoOpenClientApplication NO -WOLifebeatInterval 30 -WOLifebeatEnabled YES
-WOLifebeatDestinationPort 1085 -WOAdaptor WODefaultAdaptor -WOWorkerThreadCount 8 -WOListenQueueSize 128
-WOWorkerThreadCountMin 16 -WOWorkerThreadCountMax 256 -NSProjectSearchPath () -WOSessionTimeOut 3600
-WOApplicationName kieran-temp -WOMonitorEnabled YES -WONoPause YES -Duser.name=cheetahdeploy
-Dcheetah.dbhost=192.168.3.168 -DWODirectConnectEnabled=false -DWOStatisticsPassword=temppassword
-DEOAdaptorDebugEnabled=false -DWOAllowsConcurrentRequestHandling=true -DWOSessionTimeOut=900
-Dwk.cheetah.concurrent.VendorListBillingLongResponseTask.enableTask=false -Xms756m -Xmx1536m
[2010-11-19 13:53:37 EST] <WorkerThread1> @@@@@ monitorRequestAction returning
response to Monitor
[2010-11-19 13:53:37 EST] <WorkerThread1> @@@@@ monitorRequestAction responseDict: {commandWotaskdResponse = (
{success = true; } ); }
[2010-11-19 13:53:37 EST] <WorkerThread4>
@@@@@ monitorRequestAction received request from Monitor
[2010-11-19 13:53:37 EST] <WorkerThread4> @@@@@ monitorRequestAction requestDict:
{queryWotaskd = "INSTANCE"; }
[2010-11-19 13:53:37 EST] <WorkerThread4> @@@@@ monitorRequestAction returning
response to Monitor
[2010-11-19 13:53:37 EST] <WorkerThread4> @@@@@ monitorRequestAction responseDict: {queryWotaskdResponse =
{instanceResponse = ( {port = 2001; runningState = "STARTING"; statistics = {}; id = 1; nextShutdown = "-";
applicationName = "kieran-temp"; refusingNewSessions = false; host = "192.168.3.168"; deaths = ( 11/19/2010 13:53:13
US/Eastern ); } ); }; }
[2010-11-19 13:53:39 EST] <WorkerThread6> @@@@@ Received Lifebeat: hasStarted
kieran-temp 192.168.3.168 2001
[2010-11-19 13:53:43 EST] <main> _checkAutoRecover START
[2010-11-19 13:53:43 EST] <main> _checkAutoRecover STOP
*Hitting Stop on WOMonitor results in the following wotaskd output on the linux
machine:*
[2010-11-19 13:55:8 EST] <WorkerThread1>
@@@@@ monitorRequestAction received request from Monitor
[2010-11-19 13:55:8 EST] <WorkerThread1> @@@@@ monitorRequestAction
requestDict: {commandWotaskd = ( STOP,
{applicationName = "kieran-temp"; port = 2001; id = 1; hostName =
"192.168.3.168"; } ); }
[2010-11-19 13:55:8 EST] <WorkerThread1> !...@#$!@#$ sendInstanceRequest
creates a WOHTTPConnection
[2010-11-19 13:55:8 EST] <WorkerThread1> @@@@@ monitorRequestAction returning
response to Monitor
[2010-11-19 13:55:8 EST] <WorkerThread1> @@@@@ monitorRequestAction responseDict: {commandWotaskdResponse = ( {success
= true; },
{success = true; } ); }
[2010-11-19 13:55:8 EST] <WorkerThread0>
@@@@@ monitorRequestAction received request from Monitor
[2010-11-19 13:55:8 EST] <WorkerThread0> @@@@@ monitorRequestAction requestDict:
{queryWotaskd = "INSTANCE"; }
[2010-11-19 13:55:8 EST] <Thread-57> !...@#$!@#$ sendInstanceRequest creates a
WOHTTPConnection
[2010-11-19 13:55:8 EST] <WorkerThread0> @@@@@ monitorRequestAction returning
response to Monitor
[2010-11-19 13:55:8 EST] <WorkerThread0> @@@@@ monitorRequestAction responseDict: {queryWotaskdResponse =
{instanceResponse = ( {port = 2001; runningState = "ALIVE"; statistics = {}; id = 1; nextShutdown = "-";
applicationName = "kieran-temp"; refusingNewSessions = false; host = "192.168.3.168"; deaths = ( 11/19/2010 13:53:13
US/Eastern ); } ); }; }
[2010-11-19 13:55:8 EST] <WorkerThread6> @@@@@ Received Lifebeat: lifebeat
kieran-temp 192.168.3.168 2001
[2010-11-19 13:55:13 EST] <main> _checkAutoRecover START
[2010-11-19 13:55:13 EST] <main> _checkAutoRecover STOP
Any ideas about config changes to make this work?
On Nov 19, 2010, at 11:49 AM, Aurélien Minet wrote:
All of the listed commands are orders passed by the wotaskd to the application.
The security on this is based on where
the orders came from. Not who, no login/password, just the IP/hostname
(something like gethostbyname) to check if it is
local or not.
For not having trouble, you have to make the command hostname -f returning the
full qualified name of the server:
server.domain.tld , in order to do that you have :
_ to get a proper /etc/hosts file like:
127.0.0.1 localhost.localdomain localhost
1.2.3.4 server.domainX.tld server cname.domainY.tld
3.5.6.7 other.domainZ.tld other
...
(by default it file isn't correct on OS X too but it must be sufficiently
correct for having wostaskd orders accepted by
instances)
_ to get the hostname correctly defined in /etc/sysconfig/network (for redhat's
based distribution)
Also I would recommend that you use IP address instead of the hostname in the
JavaMonitor Hosts tab's in order to avoid
DNS problems.
Aurélien
On 11/19/2010 05:24 PM, Kieran Kelleher wrote:
Does anyone know why a WOA app running on a physical linux (centos) machine would not respond to WOMonitor "Stop" or
"Refuse New Sessions" and not display the instance statistics?
What doesn't work:
- WOMonitor "Stop" does not stop the instance on linux and neither does it indicate stopped in WOMonitor (as if
action is ignored)
- WOMonitor "Refuse New Sessions" does not stop refusing sessions on the instance and does not indicate refusing
sessions in WOMonitor (as if action is ignored)
- WOMonitor displays none of the statistics for the linux instance in app
Detail View in WOMonitor. All zeroes.
What does work for Linux instances:
- WOMonitor Start does
- WOMonitor Auto Recover does
To save time on obvious questions, here is the configuration:
- This is a mixed environment of 1 Linux and 5 OS X WOA servers.
- wotaskd is Apple's 5.4.3 version on all machines
- WOMonitor is Apple's 5.4.3 a Mac OS X machine
- The linux machine has eth0 and eth1. eth1 is on the WOA network.
- The wotaskd on the Linux box Properties file has WOHost=<eth1-ip-address>
- The linux host in WOMonitor is identified by its eth1-ip-address
Right now the only way to kill app instance on linux is:
1) remote login, lsof -i tcp:xxxx and then kill pid
2) Click an admin action in the instance itself that calls System.exit
... after which WOMonitor "sees" that the instance is stopped
Right now the only way to refuse sessions on linux instance is:
1) Fire an admin action that calls application.refuseSessions()
.... after which WOMonitor "sees" that the instance is Refusing Sessions
WOMonitor functions fine for insatnces on all Mac OS X woa servers.
Does anyone know what might be the problem?
Regards, Kieran _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-deploy mailing list ([email protected]
<mailto:[email protected]>)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-deploy/aurelien.minet%40univ-provence.fr
This email sent to [email protected]
<mailto:[email protected]>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-deploy mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-deploy/archive%40mail-archive.com
This email sent to [email protected]