On Wed, Aug 15, 2012 at 3:01 PM, Kay Schenk <[email protected]> wrote:
> > > On Wed, Aug 15, 2012 at 2:49 PM, Dave Fisher <[email protected]>wrote: > >> >> On Aug 15, 2012, at 2:29 PM, Kay Schenk wrote: >> >> > On Wed, Aug 15, 2012 at 11:15 AM, Rob Weir <[email protected]> wrote: >> > >> >> On Wed, Aug 15, 2012 at 2:05 PM, Dave Fisher <[email protected]> >> >> wrote: >> >>> >> >>> On Aug 15, 2012, at 10:28 AM, Daniel Shahaf wrote: >> >>> >> >>>> Rob Weir wrote on Wed, Aug 15, 2012 at 13:11:43 -0400: >> >>>>> On Wed, Aug 15, 2012 at 1:05 PM, Daniel Shahaf < >> [email protected]> >> >> wrote: >> >>>>>> Oliver-Rainer Wittmann wrote on Wed, Aug 15, 2012 at 16:32:21 >> +0200: >> >>>>>>> Is it possible that somebody from the Apache Infrastructure can >> >>>>>>> provide a view on which URL the traffic load was soo high that the >> >>>>>>> servers got in trouble? >> >>>>>>> >> >>>>>> >> >>>>>> POST requests to /ProductUpdateService/check.Update file >> >>>>>> >> >>>>> >> >>>>> For which subdomain, which UpdateXX.openoffice.org ? >> >>>> >> >>>> The access log doesn't say, and the error log has >> >>>> >> >>>> % fgrep /ProductUpdateService/check.Update error_log | sed -e >> >> 's#^.*/content/projects/##' | cut -d/ -f1 | sort | uniq -c >> >>>> >> >>>> EU: >> >>>> 232046 update30 >> >>>> 35548 update34 >> >>>> 76543 update35 >> >>>> >> >>>> >> >>>> US: >> >>>> 198996 update30 >> >>>> 33450 update34 >> >>>> 71117 update35 >> >>>> 0 update36 >> >>> >> >>> We don't see update32 because those do not get redirected in the same >> >> way because there is no ooo-site/trunk/content/projects/update32 >> >> >> > >> > uh oh...this should have been setup before and Oliver said he requested >> > this in the first post here. >> > >> > And you're now saying that all the previous ones have been reverted? >> >> The zone file is now: >> >> ; update.services CNAME www.openoffice.org. >> >> >> >> >> ; WARNING WARNING WARNING >> ; Changing the above entries to point to eos can overload it. Do not >> enable >> ; them unless either eos is prepared for the load or the TTL is suitably >> ; lowered >> update.services CNAME sd-web4.staroffice.de. >> update23.services CNAME sd-web2.staroffice.de. >> update24.services CNAME sd-web2.staroffice.de. >> update30.services CNAME sd-web2.staroffice.de. >> update31.services CNAME sd-web2.staroffice.de. >> update32.services CNAME sd-web2.staroffice.de. >> update33.services CNAME sd-web2.staroffice.de. >> >> >> >> >> update34.services CNAME www.openoffice.org. >> update35.services CNAME www.openoffice.org. >> update36.services CNAME www.openoffice.org. >> update38.services CNAME www.openoffice.org. >> >> >> > >> > I think we were OK until this last one, right? update32? >> >> Only yesterday's changes to DNS were reverted. >> > > OK, good...it seems we can't go below update34 -- used for OO 3.2 without > further investigation. > > Meanwhile I will delete the > > ./update30/ProductUpdateService/check.Update > > so it causes no further confusion... > ok, this is gone now...the ones that remain with numbers following updatexx are in use. /projects/updatexx/.... as well as /projects/update/ which is used for aoo34 > > >> > >> > I think the others should be re-established as they weren't causing >> > problems, were they? >> > >> > The thing is unless we go back to the code for OOo 3.1, we don't know >> what >> > it's doing. >> > >> > When I asked about this when we had issues for OOo 3.0, I was told it >> was >> > fixed in OOo 3.2, so maybe 3.1. has the same issues? >> > >> > >> > >> >> >> >>> ./update/aoo341/check.Update >> >>> ./update/ProductUpdateService/check.Update >> >>> ./update30/ProductUpdateService/check.Update >> >>> ./update34/ProductUpdateService/check.Update >> >>> ./update34/ProductUpdateService/test.Update >> >>> ./update35/ProductUpdateService/check.Update >> >>> ./update35/ProductUpdateService/test.Update >> >>> ./update36/ProductUpdateService/check.Update >> >>> ./update38/ProductUpdateService/check.Update >> >>> >> >>> It looks like 34 and 35 have been trouble, but not as bad as 30. >> >>> >> >> >> >> But haven't 34 and 35 been in production since early July? We've >> >> certainly seen plenty of downloads triggered by them. They should not >> >> be giving any errors, since the requests resolve to files on our site. >> >> >> >> I wonder, could the errors in those be caused by the outage caused by >> >> the errors in update30? >> >> >> > >> > Rob...update 30 is completely out of the question, and we simply can >> not >> > do it, and reverted it within hours when I first requested it. >> > >> > There IS an update30 directory there but it isn't actually being used, >> and >> > is just a dummy file anyway. Maybe we should just delete this one so we >> > won't get confused about this one anymore. It was setup in early stages >> of >> > testing. >> > >> > Should I just delete ./update30/ProductUpdateService/check.Update -- I >> mean >> > the whole directory. >> > >> > >> >> -Rob >> >> >> >>> Regards, >> >>> Dave >> >> >> > >> > >> > >> > -- >> > >> ---------------------------------------------------------------------------------------- >> > MzK >> > >> > "Never express yourself more clearly than you are able to think." >> > >> -- >> > Niels Bohr >> >> > > > -- > > ---------------------------------------------------------------------------------------- > MzK > > "Never express yourself more clearly than you are able to think." > -- > Niels Bohr > -- ---------------------------------------------------------------------------------------- MzK "Never express yourself more clearly than you are able to think." -- Niels Bohr
