On 19 nov 2010, at 22:52, Chuck Hill wrote: > > On Nov 19, 2010, at 1:50 PM, Kieran Kelleher wrote: > >> 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! :-) > > Niue. I don't think he had plans to do either one in Portugal. >
I must say that, in the light of NAS report http://www.nap.edu/catalog.php?record_id=12507 about the possibility of a once in a lifetime solar storm blow out in the coming years, Niue is looking more and more attractive. And of course in the light of the fruit company becoming a fruit company. At Niue we can and will prevent open competition from their apples against our turnips. > >> 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 >>> >>> >>> >>> >>> >>> >>> >> > > -- > 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/johan%40netsense.nl > > This email sent to [email protected] Johan Henselmans [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]
