[Box-Admins] box3.squeak.org off line - HELP neeeded

[Chris Muller]

On Wed, Oct 9, 2013 at 11:42 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> On Wed, Oct 09, 2013 at 10:23:06AM -0500, Chris Muller wrote:
>> > On Tue, Oct 08, 2013 at 07:54:05PM -0500, Chris Muller wrote:
>> >> I just deployed an updated image for "new trunk" at
>> >> box4.squeak.org:8888/trunk.  This is the one that uses the Magma
>> >> backend.  I haven't done any benchmarks but the response time seems
>> >> pretty snappy, even compared to regular source.squeak.org.  Could be
>> >> due to Cog, the Magma backend, or box4 being under less load than
>> >> box3.
>> >
>> > It might be all of the above. I'm thinking that the priority for the
>> > squeaksource.com image is to first get it up to date to the level of
>> > source.squeak.org, then at our leisure we can bring both of them together
>> > up to a the level that you are demonstarting with Cog and Magma. But
>> > the main thing is to get squeaksource.com stable, which is not yet the case.
>>
>> source.squeak.org is getting slow too, and it runs on an old image.
>> The work I've done to bring it to a trunk image under Cog is based on
>> the source.squeak.org image, and really not that many changes.
>>
>> > It turns out that the following snippet from the workspace that SCG provided
>> > took care of the problem for now:
>> >
>> >         " kill runaway processes "
>> >         ProcessBrowser open.
>> >         Process allInstances do: [ :each |
>> >                 each priority = 30 ifTrue: [
>> >                         each terminate ] ].
>>
>> OMG!  No wonder SS has so many problems if it is so unloved that
>> someone would arbitrarily kill processes based on their priority!
>>
>
> That's just something I found in the workspace that came with the image.
> I figured it must be there for a reason, so I tried it and it "fixed"
> the problem.
>
> You are right about one thing - SS was not getting much love. Even I, who
> knew absolutely nothing about SqueakSource before I volunteered to move
> it, was able to fix some of the worst problems. That's why I am confident
> that we can get it running reliably once we have given it a little bit
> of long-overdue attention.
>
>> > So I'm guessing that some Seaside handler got wedged, presumably concurrent
>> > with an excessive memory usage condition, and it probably failed in some way
>> > that did not let the garbage collector clean up the mess.
>>
>> SS forks the email out to Project subscribers at priority 30. See
>> SSEMailSubscription>>#versionAdded:to:.  I wonder whether that's what
>> those were?
>
> Outbound mail notification from squeaksource.com is disabled, so that
> should not have been a concern.

Which switch are you referring to that is "disabled"?  Did you check
SSProject>>#versionAdded:?  For the path of someone saving a version,
it _unconditionally_ sends out mail to all subscribers, there is no
single switch to disable that..

> Note, I still need help from someone with access to box2 to enable mail
> delivery. I don't want to install an entire mail system on box3 just
> to handle notifications from squeaksource on box3, so I expect that
> configuring box2 to accept smtp from box3 would be the right thing
> to do.

Is SMTP support not already part of box3?  Seems like a relatively
basic service we're gonna want at some point because we want to be
focusing on transitioning all responsibilities away from box2 toward
box3 and box4 anyway.