Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAGj3215hK-cA8fOQGE2upcRum0hi+3o+m9q67f42sMGJu4FnoA@mail.gmail.com>
References: <05670035-D713-4C2E-8D12-AF76C1D116C1@comcast.net>
	<502BB2F5.7060704@googlemail.com>
	<20120815170559.GA25233@tarsus.local2>
	<CAP-ksog26UFjQ+3=TJMXG7M=b3drDNgbbE_zx+dqcTd7oB3hNQ@mail.gmail.com>
	<20120815172854.GA20906@tarsus.local2>
	<76E8E6D1-F030-4139-A36B-A8538ED7C8C2@comcast.net>
	<CAP-ksoioD7K-sZKi0H_DXaqa3hZJCBzQqge0A9x=-tv=UBwB1w@mail.gmail.com>
	<CAGj3215hK-cA8fOQGE2upcRum0hi+3o+m9q67f42sMGJu4FnoA@mail.gmail.com>
Date: Wed, 15 Aug 2012 19:04:56 -0400
Message-ID: 
 <CAP-ksoj-x8DHsKkri_86JwDQ6JJ=Y6aZyEAWfF5GXnOH-=gUpQ@mail.gmail.com>
Subject: Re: Registration and Update Services - What Will Be The Load?
From: Rob Weir <robweir@apache.org>
To: ooo-dev@incubator.apache.org
Content-Type: text/plain; charset=UTF-8

On Wed, Aug 15, 2012 at 5:29 PM, Kay Schenk <kay.schenk@gmail.com> wrote:
> On Wed, Aug 15, 2012 at 11:15 AM, Rob Weir <robweir@apache.org> wrote:
>
>> On Wed, Aug 15, 2012 at 2:05 PM, Dave Fisher <dave2wave@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.s@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.
>

What is the issue with update 30?  The fact that it does a POST?  I
don't that would rule it out altogether.  But we would need to treat
it specially.  For example, we could redirect to an isolated server,
at Apache or outside, that is able/willing to handle it.  If we run it
for a month or two we should get the bulk of the upgrades.

Or was there some other issue?

> 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