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?
I think we were OK until this last one, right? update32?
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
