OK, first of all. Thanks to all who tried to help.
Miguel Arroz - you are a very smart man, and you should never give up your WO
career for goat-herding or farming in Portugal! :-)
So here is what worked for the finicky multi-IP linux box and its on/off
relationship with wotaskd:
I added Miguel's WOHostUtilities to ERExtensions, built and deployed the app.
Note, WOHost needed to be set in wotaskd's Properties to the
WoHost=192.168.3.168. Setting it specifically to 127.0.0.1 resulted in
WOMonitor red error message "Failed to contact 192.168.3.168-1085". Not setting
it at all resulted in that Linux wotaskd not even receiving requests from
WOMonitor (confirmed with wotaskd debugging enabled) and not responding at all
to START instance requests.
In WOMonitor I added a single argument with a list of all IP addresses of all
wotaskd hosts in the WOA subnet, like this:
-Dcom.survs.localhostIps=(192.168.3.140,192.168.3.160,192.168.3.163,192.168.3.165,192.168.3.161,192.168.3.161,192.168.3.168)
Now WOMonitor works for linux instances the same as for Mac OS X instances.
Yay! :-)
I am guessing (but not going messing with this server right now since it has
other services running on it that cannot be stopped for me to experiment) that
if the eth0 was on the WOA subnet, none of this might be neccessary.
Either way, I think it is worthwhile to drop Miguel's class into ERExtensions
since ERExtensions, IIRC, pushes itself to the top of the classpath, and since
Miguel's class functions the same as the original WO one if the localIps
property is not set. Of course I will change the property name to have a
er.extensions.* prefix.
Regards, Kieran
On Nov 19, 2010, at 4:29 PM, Chuck Hill wrote:
>
> On Nov 19, 2010, at 1:14 PM, Kieran Kelleher wrote:
>
>> I am not using DNS for these few machines, just their IP addresses.
>
> WO can be quite particular about DNS, despite what you want to do. ;-)
>
>
>>
>> hostname -f returns "localhost.localdomain"
>>
>> Initially the default wotaskd resulted in WOMonitor not even being able to
>> start instances on the linux server, so adding WOHost=192.168.3.168 solved
>> the START instance problem.
>>
>>
>> On Nov 19, 2010, at 2:55 PM, Aurélien Minet wrote:
>>
>>> 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/chill%40global-village.net
>>
>> This email sent to [email protected]
>
> --
> Chuck Hill Senior Consultant / VP Development
>
> Practical WebObjects - for developers who want to increase their overall
> knowledge of WebObjects or who are trying to solve specific problems.
> http://www.global-village.net/products/practical_webobjects
>
>
>
>
>
>
>
_______________________________________________
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]
