I think it might work if you put 192.168.3.168 on eth0 and 192.168.1.168 on
eth1. Does en0 on OS X servers are on 192.168.3.0/24?
> Hi Aurélien,
>
> OK, we are only using IP addresses in WOMonitor, no hostnames at all.
>
> The linux server has two interfaces
>
> eth0 192.168.1.168
> eth1 192.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.1 localhost.localdomain localhost
> ::1 localhost6.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])
>>> Help/Unsubscribe/Update your Subscription:
>>> http://lists.apple.com/mailman/options/webobjects-deploy/aurelien.minet%40univ-provence.fr
>>>
>>> This email sent to [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/probert%40macti.ca
>
> This email sent to [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]
