On Wed, Aug 15, 2012 at 2:49 PM, Dave Fisher <dave2w...@comcast.net> wrote:
>
> On Aug 15, 2012, at 2:29 PM, Kay Schenk wrote:
>
> > On Wed, Aug 15, 2012 at 11:15 AM, Rob Weir <robw...@apache.org> wrote:
> >
> >> On Wed, Aug 15, 2012 at 2:05 PM, Dave Fisher <dave2w...@comcast.net>
> >> 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 <
> d...@daniel.shahaf.name>
> >> 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...
> >
> > 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
