incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: Registration and Update Services - What Will Be The Load?
Date Thu, 16 Aug 2012 02:04:38 GMT

On Aug 15, 2012, at 6:53 PM, Rob Weir wrote:

> On Wed, Aug 15, 2012 at 7:31 PM, Kay Schenk <kay.schenk@gmail.com> wrote:
>> On Wed, Aug 15, 2012 at 4:04 PM, Rob Weir <robweir@apache.org> wrote:
>> 
>>> 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?
>>> 
>> 
>> The Apache web server, of which AOO is a part, does not allow POSTs so when
>> I had infra enable this and redirect the old update30 to the web server, it
>> caused MANY errors in a very short period of time (about an hour) and Joe
>> reverted it rather quickly.  THis was like back in early March or
>> something when I was playing around. The update feed itself didn't even DO
>> anything but redirect them to a URL (in theory) it was the POST in the code
>> for OOo 3.0 that caused all the havoc. When I inquired about this on this
>> list, I was told yes, this WAS the case for 3.0 but had been fixed with, I
>> thought 3.2.
>> 
>> Anyway, as far as I know, this is the only issue.
>> 
>> I was pretty wary initially about running the feed through the web server
>> but was told we should be fine (this after Joe reverted the update30 in
>> March) -- and I think we have been for the most part. But, yes, we need
>> another box with a web server that would accept POSTs to deal with this --
>> 3.0, and it looks like 3.1.
>> 
> 
> OK.  That's the impression I had as well -- POST was disabled in
> general on ASF servers.  We're not going to be able to change that.
> But the traffic from permitted POSTs will be far less than the errors
> and retries  generated from disallowed POSTs.   So if we can find a
> volunteer to host this traffic on their website, then we could have
> the redirects go there rather than to openoffice.org or staroffice.de.
>  This would not need to be a host volunteering to do this forever.  I
> think if we ran it for 2 months we'd get almost everyone, since the
> upgrade checks occur once a week by default.
> 
> But we can discuss this more after AOO 3.4.1 is out.    No sense
> tempting the OOo 3.1 users to upgrade to AOO 3.4.0 today and then send
> them a notification AOO 3.4.1 a week later.  That would be annoying.

Agreed. It may be we can get an Infra VM - ooo-slop. Put a simple apache server with POST
and keep the logs for our own analysis. If it crashes only the update process is harmed.

I will close the existing JIRA and then open another explicitly for when we have this decided.

Regards,
Dave

> 
> -Rob
> 
>> 
>>>> 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


Mime
View raw message