On Thu, Aug 5, 2010 at 8:03 AM, Brian Bartman <bbartmanboost@gmail.com> wrote:

On Thu, Aug 5, 2010 at 8:22 AM, John Maddock <boost.regex@virgin.net> wrote:

...

Anyone any ideas?  SVN has been almost impossibly slow the last few days, and today I can't connect at all :-(

It seems the website is also down.

Not sure if it went back up since then, but http://www.boost.org/doc/ yields a "403 Forbidden" error right now. Thanks, --DD

On 5 August 2010 22:55, Dominique Devienne <ddevienne@gmail.com> wrote:

Not sure if it went back up since then, but http://www.boost.org/doc/ yields a "403 Forbidden" error right now.

I think something is wrong with the checkout of the live site, as the beta site is fine. AFAICT nothing has changed in the repository that could cause this. Daniel

I just got this. I'll put the 1.43 documentation up somewhere until we've sorted out something better. Daniel ---------- Forwarded message ---------- From: DongInn Kim <dikim@osl.iu.edu> Date: 5 August 2010 23:53 Subject: Re: [boost] SVN either down or slowing to a crawl? (fwd) To: Jeremiah Willcock <jewillco@osl.iu.edu>, Daniel James <dnljms@gmail.com>, David Abrahams <dave@boostpro.com> Hi Daniel, My name is DongInn Kim, systems administrator in the OSL. I have been looking on the web server for a couple of days on wowbagger because of the very high loadaverage on it. The high loadaverage seems to be from most pages related to the zip files under http://www.boost.org/doc/ because whenever the page is accessed, the zip file(s) are decompressed and compressed back and then the page can show their contents. These compression and decompression processes have used a lot of resources on wowbagger and they made the server machine almost not usable. I first blocked the crawlers' access and watched any big changes on the loadaverage. At the beginning, it seems to be fine but eventually the loadaverage went back to high. It seems that many people need to access the pages. So, I had to block the doc/ path for a while to see if Rene or any boost guys who are working on the doc page could help out this issue. Without blocking the pages, I can not really manage all the other services on wowbagger any more. I am really sorry for the late response but I expected that someone who I talked early about this issue could transfer my words to the list. Would it be OK if I talk to David Abrahams or anyone else expecting him to transfer my words for the future issues? Regards, -ps- Can you please forward this email to the boost list?

Daniel James wrote:

...

From: DongInn Kim <dikim@osl.iu.edu>

My name is DongInn Kim, systems administrator in the OSL. I have been looking on the web server for a couple of days on wowbagger because of the very high loadaverage on it.

The high loadaverage seems to be from most pages related to the zip files under http://www.boost.org/doc/ because whenever the page is accessed, the zip file(s) are decompressed and compressed back and then the page can show their contents.

Quick update, I'm working on a solution to this. It's mostly done, the delay is now just down to us living in different time zones. But the server's still very slow so there could be another issue. Although, that could also be due to the zipped pages that are still being served on the beta site and for regression test results. I'm deliberately breaking the beta site's documentation to see if that will help. I've also changed a couple of links to go to a copy of boost on sourceforge - although this is only a temporary measure, and still leaves a lot of broken links.

There's another issue with the server, it seems. When I do SVN commit, it never finishes, e.g.: ghost@wind:~/Work/Boost/boost-svn/tools/build/v2$ svn ci Waiting for Emacs... Sending v2/engine/src/compile.c Sending v2/tools/builtin.py Transmitting file data .. stays this way for many minutes (at least 10). However, I have already received commit email about this commit. So, it seems like something prevents SVN server from telling the client that commit is actually done. Killing the client, together with 'svn cleanup', together with 'svn up' works around this. This started to happen 3 days ago, and I'm using at least two different network routes. I have svn 1.6.5 locally. Any ideas? - Volodya